On Wed, Jun 12, 2019 at 03:55:59PM +0200, Alexandre Ratchov wrote:
> Currenty USB device driver code has no way to obtain how many frames
> can be scheduled on the HC. If it attempts to schedule too many
> frames, usbd_transfer() fails or silently misbehaves.
>
> For audio this is a big problem
This has come up a few times before. For background, the default rule for doas
is to copy a few environment settings from the user and omit the rest. This is
to prevent confusion, and also supposedly for security. However, some of the
alleged safe variables like PATH probably aren't that safe. And
> From: "Sven M. Hallberg"
> Date: Wed, 12 Jun 2019 23:18:24 +0200
>
> Mark Kettenis on Tue, Jun 11 2019:
> > The drm(4) codebase really needs multi-threaded task queues [...]
> >
> > The diff also starts 4 threads for each workqueue that gets created by
> > the drm(4) layer. The number 4 is a
Mark Kettenis on Tue, Jun 11 2019:
> The drm(4) codebase really needs multi-threaded task queues [...]
>
> The diff also starts 4 threads for each workqueue that gets created by
> the drm(4) layer. The number 4 is a bit arbitrary but it is the
> number of threads that Linux creates per CPU for a
On Thu, Jun 06, 2019 at 02:14:05PM +0200, Christian Weisgerber wrote:
> Björn Ketelaars:
>
> > Diff below is based on the latest diff from naddy@. Changes:
> > - reallocarray likes type_t, as such changes type of nxdev and i;
> > - use reallocarray instead of malloc as xdev is initialised as
Currenty USB device driver code has no way to obtain how many frames
can be scheduled on the HC. If it attempts to schedule too many
frames, usbd_transfer() fails or silently misbehaves.
For audio this is a big problem because the max frames count
determines the block size which must be reported
On 6/11/19 2:36 PM, Sebastian Benoit wrote:
Hi,
some feedback below.
Renaud: maybe wait for feedback from florian or gilles until
acting on my comments, sometimes sending diffs to fast creates more work ;)
/Benno
As suggested by benno@
removal of the global variable
removal of KEYTYPE
On Wed, Jun 12, 2019 at 12:55:01PM +0300, Lauri Tirkkonen wrote:
> On Tue, Jun 11 2019 14:40:03 +0100, Jason McIntyre wrote:
> > On Tue, Jun 11, 2019 at 03:11:03PM +0300, Lauri Tirkkonen wrote:
> > > Hi, trivial manpage diff.
> > >
> >
> > fixed, thanks.
> > jmc
>
> I noticed the followup
While working on Tx aggregation I noticed that TCP streams will start
stalling whenever MiRa decides to start sending frames at Tx rates
which the AP tends to fail to receive. This means we're dropping far
too many frames while trying to find an optimal Tx rate to use.
The problem can be observed
On Tue, Jun 11 2019 14:40:03 +0100, Jason McIntyre wrote:
> On Tue, Jun 11, 2019 at 03:11:03PM +0300, Lauri Tirkkonen wrote:
> > Hi, trivial manpage diff.
> >
>
> fixed, thanks.
> jmc
I noticed the followup commit that changes the canonical option name to
'Hostname'. I also like that
On Wed, Jun 12, 2019 at 08:12:04AM +0200, Florian Obser wrote:
>
> I had a look yesterday and it looks mostly OK.
> Something came up and I won't be around the next days.
>
> Someone can put it and and we can tweak it in tree or we wait a few
> days.
>
okie dokie, will commit tonight when I
> Date: Wed, 12 Jun 2019 17:04:10 +1000
> From: Jonathan Gray
>
> On Tue, Jun 11, 2019 at 09:10:46PM +0200, Mark Kettenis wrote:
> > The drm(4) codebase really needs multi-threaded task queues since the
> > code has taks that wait for the completion of other tasks that are
> > submitted to the
On Tue, Jun 11, 2019 at 09:10:46PM +0200, Mark Kettenis wrote:
> The drm(4) codebase really needs multi-threaded task queues since the
> code has taks that wait for the completion of other tasks that are
> submitted to the same task queue. Thank you Linux...
>
> Unfortunately the code also needs
i backed this out before the 6.5 release because of bad interactions
with virtual interfaces like vlan and trunk. those should now be fixed,
so we can try the other backpressure mechanism again.
the summary is that we count the number of attempts to queue packets for
the system to process rather
I had a look yesterday and it looks mostly OK.
Something came up and I won't be around the next days.
Someone can put it and and we can tweak it in tree or we wait a few
days.
On Tue, Jun 11, 2019 at 01:37:24PM +0200, Renaud Allard wrote:
>
>
> On 6/11/19 10:17 AM, Renaud Allard wrote:
> >
15 matches
Mail list logo