Hi,
Backlight on multiple laptops will go down but not up when using brightness
keys.
Compare new brightness level to min/max values in sc_bcl[] instead.
Diff below restores backlight up function.
Index: dev/acpi/acpivout.c
===
RCS
km_alloc(9) is still not a full replacement for uvm_km_alloc(9). The
latter allows the protections of the allocation to be changed to
PROT_EXEC via uvm_map_protect(9). This is needed at least by the sti(4)
driver.
Diff below changes km_alloc(9) to allow PROT_EXEC in maxprot. With this
it is pos
Hi Scott & Jason,
Jason McIntyre wrote on Sat, Nov 02, 2019 at 06:16:49PM +:
> On Sat, Nov 02, 2019 at 12:32:30PM -0500, Scott Cheloha wrote:
>> Cite the paper describing the timing wheel. PDF here:
>>
>> http://www.cs.columbia.edu/~nahum/w6998/papers/ton97-timing-wheels.pdf
>>
>> The auth
On Sat, Nov 2, 2019 at 4:34 AM Martin Pieuchot wrote:
> uvm_km_alloc(9) has never been used in amd64's pmap. pool_get(9) is the
> thing since its import by mickey@.
>
> ok?
>
ok guenther@
On Sat, Nov 02 2019, Klemens Nanni wrote:
> On Sat, Nov 02, 2019 at 12:32:09PM +0100, Jeremie Courreges-Anglas wrote:
>> ftp(1) is not nc(1), I'd be surprised if our current ftp(1) was ported
>> to another OS. :)
> Meh, stupid me.
>
> Diff looks good so far, I can test it with miniroot and/or bsd.
On Sat, Nov 02, 2019 at 12:32:30PM -0500, Scott Cheloha wrote:
> Cite the paper describing the timing wheel. PDF here:
>
> http://www.cs.columbia.edu/~nahum/w6998/papers/ton97-timing-wheels.pdf
>
> The authors have an older paper describing the same idea, from 1987:
>
> http://www.cs.columbia.e
Cite the paper describing the timing wheel. PDF here:
http://www.cs.columbia.edu/~nahum/w6998/papers/ton97-timing-wheels.pdf
The authors have an older paper describing the same idea, from 1987:
http://www.cs.columbia.edu/~nahum/w6998/papers/sosp87-timing-wheels.pdf
but the 1997 version contain
On Sat, Nov 02, 2019 at 02:24:26PM +0100, Claudio Jeker wrote:
> Refactor the TAL loading code a bit (move the file parsing back into
> tal.c) and adjust the regress test to use this new function. This fixes
> the regress test and makes the code a bit nicer.
>
> OK?
> --
> :wq Claudio
>
> Index:
On Sat, Nov 02, 2019 at 01:18:53PM +, Stuart Henderson wrote:
> On 2019/11/01 19:16, Theo de Raadt wrote:
> > Ted Unangst wrote:
> >
> > > Theo de Raadt wrote:
> > > > What about all the other users who aren't in staff?
> > > >
> > > > I think the approach is right. Push non-interactive dow
Refactor the TAL loading code a bit (move the file parsing back into
tal.c) and adjust the regress test to use this new function. This fixes
the regress test and makes the code a bit nicer.
OK?
--
:wq Claudio
Index: usr.sbin/rpki-client/extern.h
==
uvm_km_alloc(9) has never been used in amd64's pmap. pool_get(9) is the
thing since its import by mickey@.
ok?
Index: arch/amd64/amd64/pmap.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/pmap.c,v
retrieving revision 1.135
diff -u -p
On 2019/11/01 19:16, Theo de Raadt wrote:
> Ted Unangst wrote:
>
> > Theo de Raadt wrote:
> > > What about all the other users who aren't in staff?
> > >
> > > I think the approach is right. Push non-interactive down.
> >
> > The same then for src build user?
>
> Well, that's different. Most
On Sat, Nov 02, 2019 at 12:32:09PM +0100, Jeremie Courreges-Anglas wrote:
> ftp(1) is not nc(1), I'd be surprised if our current ftp(1) was ported
> to another OS. :)
Meh, stupid me.
Diff looks good so far, I can test it with miniroot and/or bsd.rd on
amd64 and/or macppc if you want.
On Sat, Nov 02 2019, Klemens Nanni wrote:
> On Sat, Nov 02, 2019 at 12:03:17PM +0100, Jeremie Courreges-Anglas wrote:
>> The magic trick is funopen, which is not portable but I doubt that's
>> a problem.
> A lot of Linux distributions use or at least package our netcat and I'm
> really glad they d
On Sat, Nov 02, 2019 at 12:03:17PM +0100, Jeremie Courreges-Anglas wrote:
> The magic trick is funopen, which is not portable but I doubt that's
> a problem.
A lot of Linux distributions use or at least package our netcat and I'm
really glad they do; no idea what how those would work around
funope
This unifies the TLS/non-TLS code paths, kills a bunch of local code,
saves some precious text size and makes the code easier to follow IMO.
The magic trick is funopen, which is not portable but I doubt that's
a problem. I added a tls_handshake() call so that TLS errors are
spotted earlier (els
On Sat, Nov 02, 2019 at 08:20:08AM +0100, Otto Moerbeek wrote:
> On Fri, Nov 01, 2019 at 10:43:27PM +0100, Remi Locherer wrote:
>
> > On Fri, Nov 01, 2019 at 09:53:28PM +0100, Florian Obser wrote:
> > > On Fri, Nov 01, 2019 at 09:45:37PM +0100, Florian Obser wrote:
> > > > On Fri, Nov 01, 2019 at
seems to be working fine on my gen2 X1
On Wed, Oct 30, 2019 at 02:44:17PM +0100, Stefan Sperling wrote:
> This switches 7260 iwm(4) devices to the iwm-7260-17 firmware image
> which has been available via fw_update in -current for a while.
>
> iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wirele
> Date: Sat, 2 Nov 2019 10:55:30 +0100
> From: Martin Pieuchot
>
> This function is just a wrapper on top of uvm_unmap(), it has its own
> file and is called only 3 times in the kernel. Getting rid of it makes
> the overall UVM simpler, ok?
>
> Index: sys/conf/files
> ==
This function is just a wrapper on top of uvm_unmap(), it has its own
file and is called only 3 times in the kernel. Getting rid of it makes
the overall UVM simpler, ok?
Index: sys/conf/files
===
RCS file: /cvs/src/sys/conf/files,v
r
On Fri, Nov 01, 2019 at 10:43:27PM +0100, Remi Locherer wrote:
> On Fri, Nov 01, 2019 at 09:53:28PM +0100, Florian Obser wrote:
> > On Fri, Nov 01, 2019 at 09:45:37PM +0100, Florian Obser wrote:
> > > On Fri, Nov 01, 2019 at 09:35:07PM +0100, Remi Locherer wrote:
> > > > On Thu, Oct 31, 2019 at 08
21 matches
Mail list logo
