This adds support for SAS3 (SAS3004, 3008, 3104) chips in mpii(4).
As far as we're concerned, these are the same as the supported SAS2
chips, just with a different sgl layout. I've tested this on a Lenovo N2215:
mpii0 at pci1 dev 0 function 0 "Symbios Logic SAS3008" rev 0x02: msi
mpii0: N2215, fi
On 13/09/2016 01:43, Theo de Raadt wrote:
> I honestly don't see the value these annotations add, especially for
> such tiny commands.
Ok, fair enough.
Sevan
I honestly don't see the value these annotations add, especially for
such tiny commands.
If this procedure was followed through with, it is 3 additional lines
in every man page.
Frankly, who cares?
I also find it somewhat disturbing how many incorrect annotations I've
been seeing. It may be bet
Hello,
clri showed up in V6 UNIX
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man8/clri.8
Attached patch adds a history section to man page.
Sevan
Index: sbin/clri/clri.8
===
RCS file: /cvs/src/sbin/clri/clri.8,v
retrieving
Philip Guenther wrote:
> So what's protecting the state that you're waiting for the change to
> occur in? If it's the mutex, then why are you accessing it with only
> the rwlock early on? If it's the rwlock then how to prevent a
> lost-wakeup by a thread on another CPU getting in between the
> rw
On Mon, Sep 12, 2016 at 10:18:14AM +0200, Martin Pieuchot wrote:
>
> I just committed your driver, with some tweaks in the manpage.
Great, thank you!
> > It is quite likely related to this discussion:
> >
> > http://marc.info/?l=openbsd-misc&m=140529029513846&w=2
> > http://marc.info/?l=openbsd
On Mon, Sep 12, 2016 at 4:29 AM, Ted Unangst wrote:
...
> Something feels a little weird about this. Usually you want to keep the rwlock
> while sleeping.
Yes, that's usually the point of the lock, but when you need a
condition-variable for changes in the state protected by an rwlock,
you need rw
boggle(6) can only handle board specifications that consist of lower
case letters. Also, it will only handle one boardspec per invocation
and ignore the rest. However, currently boggle(6) only checks whether
the first letter of the first boardspec is lower case and whether the
length is correct.
On Mon, Sep 12, 2016 at 1:49 AM, Martin Pieuchot wrote:
> I'd like to use a write lock to serialize accesses to ip_output(). This
> will be used to guarantee that atomic code sections in the socket layer
> stay atomic when the input/forwarding path won't run under KERNEL_LOCK().
>
> For such purp
On 29 August 2016 at 19:10, Mike Belopuhov wrote:
> Due to a recent change in -current the socket sending routine
> has started producing small data packets crossing memory page
> boundary. This is not supported by Xen and kernels with this
> change will experience broken bulk TCP transmit behavi
On Mon, 12 Sep 2016 19:10:32 +0200, Jeremie Courreges-Anglas wrote:
> It seems that date(1) used to have support for timed(8), this support
> has been removed in 2011. Let's remove a confusing reference to "remote
> time".
OK millert@.
- todd
It seems that date(1) used to have support for timed(8), this support
has been removed in 2011. Let's remove a confusing reference to "remote
time".
ok?
Index: date.1
===
RCS file: /cvs/src/bin/date/date.1,v
retrieving revision 1.
Is this any slower on very large compressions or decompressions?
> Ted Unangst wrote:
> > This splits gzip into two processes, such that the heavy lifting is done in
> > a
> > process with even fewer privileges. The idea is the child decompresses the
> > data and feeds it to the parent over a pip
Ted Unangst wrote:
> This splits gzip into two processes, such that the heavy lifting is done in a
> process with even fewer privileges. The idea is the child decompresses the
> data and feeds it to the parent over a pipe. There's also a control pipe used
> for some metadata that needs to be passed
> Sure! Long live etherip(4).
Chers!
On Mon, Sep 12, 2016 at 01:34:25PM +0200, Martin Pieuchot wrote:
> bridge(4) no longer accept gif(4) interfaces, so kill no dead code, ok?
Sure! Long live etherip(4).
> Index: net/if_gif.c
> ===
> RCS file: /cvs/src/sys/net/if_gif.c
On Mon, Sep 12, 2016 at 11:15:21AM +0200, Martin Pieuchot wrote:
> soaccept() is always called at IPL_SOFTNET, so assert it instead of
> raising the SPL level recursively. This is not a problem currently
> but will be one as soon as we use a non-recursive rwlock.
>
> ok?
OK claudio (I bet there
TCP timers end up calling ip_output(), which will soon require that the
caller holds a rwlock.
In order to do that, I diff below changes 'struct tcptimer' to become a
tuple of (timeout, task). When a timeout fires, the corresponding task
gets scheduled.
I'm currently using the ``softnettq'' to s
bridge(4) no longer accept gif(4) interfaces, so kill no dead code, ok?
Index: net/if_gif.c
===
RCS file: /cvs/src/sys/net/if_gif.c,v
retrieving revision 1.85
diff -u -p -r1.85 if_gif.c
--- net/if_gif.c13 Apr 2016 11:41:15 -00
Martin Pieuchot wrote:
> I'd like to use a write lock to serialize accesses to ip_output(). This
> will be used to guarantee that atomic code sections in the socket layer
> stay atomic when the input/forwarding path won't run under KERNEL_LOCK().
>
> For such purpose I'll have to convert some tsl
On Mon, 12 Sep 2016 10:49:03 +0200
Martin Pieuchot wrote:
> I'd like to use a write lock to serialize accesses to ip_output().
> This will be used to guarantee that atomic code sections in the
> socket layer stay atomic when the input/forwarding path won't run
> under KERNEL_LOCK().
>
> For such
soaccept() is always called at IPL_SOFTNET, so assert it instead of
raising the SPL level recursively. This is not a problem currently
but will be one as soon as we use a non-recursive rwlock.
ok?
Index: kern/uipc_socket.c
===
RCS f
I'd like to use a write lock to serialize accesses to ip_output(). This
will be used to guarantee that atomic code sections in the socket layer
stay atomic when the input/forwarding path won't run under KERNEL_LOCK().
For such purpose I'll have to convert some tsleep(9) to an msleep(9)-like
funct
On 11/09/16(Sun) 15:10, Mike Burns wrote:
> On 2016-09-11 16.14.44 +0200, Frank Groeneveld wrote:
> > I've also made some progress regarding the scaling bug. It seems the
> > device is not properly detached from Xorg when it is unplugged, because
> > the log starts getting spammed with loads of mes
24 matches
Mail list logo
