Otto Moerbeek writes:
> On Tue, Jun 14, 2016 at 06:14:05PM +0200, Jeremie Courreges-Anglas wrote:
>
>> Marc Peters writes:
>>
>> > Hi,
>> >
>> > i just did an installation of a HP DL360 Gen9 to test UEFI installations
>> > with 5.9. I just accepted most of the defaults and did this for the
>> >
On 13.06.2016 12:52, Martin Pieuchot wrote:
On 10/06/16(Fri) 21:09, Mark Kettenis wrote:
Date: Fri, 10 Jun 2016 17:20:18 +0100
From: Stuart Henderson
On 2016/06/10 16:05, Mark Kettenis wrote:
In any case this is something we can figure out once the code hits the
tree. Unless mpi@ is still un
On Thu, Jun 16, 2016 at 12:53:24AM +0200, Giovanni Bechis wrote:
> On Wed, Jun 15, 2016 at 03:49:46PM -0700, Mike Larkin wrote:
> > On Thu, Jun 16, 2016 at 12:05:51AM +0200, Giovanni Bechis wrote:
> > > Hi,
> > > this diff enables suspend and hibernate through fn keys in Toshiba
> > > laptops.
> >
On Wed, Jun 15, 2016 at 03:49:46PM -0700, Mike Larkin wrote:
> On Thu, Jun 16, 2016 at 12:05:51AM +0200, Giovanni Bechis wrote:
> > Hi,
> > this diff enables suspend and hibernate through fn keys in Toshiba laptops.
> > Comments ? Ok ?
> > Cheers
> > Giovanni
>
> If you fix your spelling mistak
On Thu, Jun 16, 2016 at 12:05:51AM +0200, Giovanni Bechis wrote:
> Hi,
> this diff enables suspend and hibernate through fn keys in Toshiba laptops.
> Comments ? Ok ?
> Cheers
> Giovanni
If you fix your spelling mistake for "Hibernate" correctly below,
sure.
-ml
> Index: acpitoshiba.c
> =
Hi,
this diff enables suspend and hibernate through fn keys in Toshiba laptops.
Comments ? Ok ?
Cheers
Giovanni
Index: acpitoshiba.c
===
RCS file: /var/cvs/src/sys/dev/acpi/acpitoshiba.c,v
retrieving revision 1.5
diff -u -p -r1.5 ac
On Wed, Jun 15, 2016 at 08:26:01PM +0200, Marcus Glocker wrote:
> On Wed, Jun 15, 2016 at 10:11:19AM -0700, Philip Guenther wrote:
>
> > On Wed, Jun 15, 2016 at 7:22 AM, Martin Pieuchot wrote:
> > > On 11/06/16(Sat) 16:44, Marcus Glocker wrote:
> > >> Currently one can open multiple instances of
> On Wed, 15 Jun 2016 19:01:23 +0200, Mark Kettenis wrote:
>
>> I don't really consider it to be terribly important to rename the
>> efifb(4). The chromebooks are weird machines, and I don't expect the
>> coreboot-based framebuffer to show up on many systems.
>
> Agreed, just keep it as efifb(4).
On Wed, Jun 15, 2016 at 10:11:19AM -0700, Philip Guenther wrote:
> On Wed, Jun 15, 2016 at 7:22 AM, Martin Pieuchot wrote:
> > On 11/06/16(Sat) 16:44, Marcus Glocker wrote:
> >> Currently one can open multiple instances of /dev/ttyU* since ucom(4)
> >> just checks 'TS_ISOPEN' against /dev/cuaU* a
On Mon, 13 Jun 2016 16:49:01 +0200
Vincent Gross wrote:
>
> While validating source address inside selection functions is the
> right direction, I don't think it would be a good thing to extend
> further in_selectsrc() prototype. However it is easy to add a check
> while processing cmsg.
>
> rev
On Wed, Jun 15, 2016 at 10:07:12AM +0200, Michal Mazurek wrote:
> It was removed in March, so remove the last mention of it.
>
fixed, thanks.
jmc
> Index: share/man/man9/ktrace.9
> ===
> RCS file: /cvs/src/share/man/man9/ktrace.9,v
On Wed, Jun 15, 2016 at 7:22 AM, Martin Pieuchot wrote:
> On 11/06/16(Sat) 16:44, Marcus Glocker wrote:
>> Currently one can open multiple instances of /dev/ttyU* since ucom(4)
>> just checks 'TS_ISOPEN' against /dev/cuaU* access. There are quiet a
>> lot of flags in ucom.c so it's a bit difficul
On Wed, 15 Jun 2016 19:01:23 +0200, Mark Kettenis wrote:
> I don't really consider it to be terribly important to rename the
> efifb(4). The chromebooks are weird machines, and I don't expect the
> coreboot-based framebuffer to show up on many systems.
Agreed, just keep it as efifb(4). If we re
> From: Bryan Vyhmeister
> Date: Wed, 15 Jun 2016 09:54:08 -0700
>
> On Wed, Jun 15, 2016, at 09:34 AM, Bryan Steele wrote:
> > On Wed, Jun 15, 2016 at 12:32:00PM -0400, Bryan Steele wrote:
> > > On Wed, Jun 15, 2016 at 11:23:53AM -0500, joshua stein wrote:
> > > > Any ideas for a new name?
> > >
On Wed, Jun 15, 2016, at 09:34 AM, Bryan Steele wrote:
> On Wed, Jun 15, 2016 at 12:32:00PM -0400, Bryan Steele wrote:
> > On Wed, Jun 15, 2016 at 11:23:53AM -0500, joshua stein wrote:
> > > Any ideas for a new name?
> >
> > NetBSD calls their equivalent driver genfb(4).
>
> I wonder if it could be
On Wed, Jun 15, 2016 at 12:32:00PM -0400, Bryan Steele wrote:
> On Wed, Jun 15, 2016 at 11:23:53AM -0500, joshua stein wrote:
> > On Tue, 14 Jun 2016 at 07:22:14 +0200, Joerg Jung wrote:
> > > > We should not get hung up too much about the driver name. If it is
> > > > felt that efifb(4) is inappr
On Wed, Jun 15, 2016 at 11:23:53AM -0500, joshua stein wrote:
> On Tue, 14 Jun 2016 at 07:22:14 +0200, Joerg Jung wrote:
> > > We should not get hung up too much about the driver name. If it is
> > > felt that efifb(4) is inappropriate for these chromebooks with
> > > coreboot, we can always renam
Ah ok I may have a not too updated mirror then I updated locally like 1h
ago. Thanks !
On 15 June 2016 at 17:28, Todd C. Miller wrote:
> On Wed, 15 Jun 2016 17:26:46 +0100, David CARLIER wrote:
>
> > maybe someone already mentioned it, but I tried to compile the kernel
> today
> > and
> > in sys
On Wed, 15 Jun 2016 17:26:46 +0100, David CARLIER wrote:
> maybe someone already mentioned it, but I tried to compile the kernel today
> and
> in sys/netinet/udp_usrreq.c, line 937 might contain an extra parenthesis
> after the first condition
>
> ie
>
> if ((inp->inp_flags & INP_IPSECFLOWINFO)
Hi all,
maybe someone already mentioned it, but I tried to compile the kernel today
and
in sys/netinet/udp_usrreq.c, line 937 might contain an extra parenthesis
after the first condition
ie
if ((inp->inp_flags & INP_IPSECFLOWINFO) != 0
*)*
Hope it s useful.
Regards.
On Tue, 14 Jun 2016 at 07:22:14 +0200, Joerg Jung wrote:
> > We should not get hung up too much about the driver name. If it is
> > felt that efifb(4) is inappropriate for these chromebooks with
> > coreboot, we can always rename the driver.
>
> Yes, renaming makes sense then.
Any ideas for a ne
On 11/06/16(Sat) 16:44, Marcus Glocker wrote:
> Currently one can open multiple instances of /dev/ttyU* since ucom(4)
> just checks 'TS_ISOPEN' against /dev/cuaU* access. There are quiet a
> lot of flags in ucom.c so it's a bit difficult to understand what the
> initial idea was. But moving the '
Works for me[tm]; I guess more tests couldn't hurt tough...
OK florian
On Tue, Jun 14, 2016 at 12:02:34PM +0200, Martin Pieuchot wrote:
> Instead of dereferencing ``rt->rt_ifa'' to get the address, let's use
> ``rt_addr''.
>
> ok?
>
>
> Index: netinet/in_pcb.c
> ===
KTRFAC_PLEDGE on its own isn't very useful, but this change makes it
possible to recreate the default string.
Make the default in the manpage more obvious.
Also ansify getpoints().
Index: usr.bin/ktrace/ktrace.1
===
RCS file: /cvs/
It was removed in March, so remove the last mention of it.
Index: share/man/man9/ktrace.9
===
RCS file: /cvs/src/share/man/man9/ktrace.9,v
retrieving revision 1.10
diff -u -p -r1.10 ktrace.9
--- share/man/man9/ktrace.9 12 Sep 2015
The documentation (man KTRPOINT) says:
KTRPOINT(struct proc *p, int type);
...
The KTRPOINT() macro should be used before calling any of the other
tracing functions to verify that tracing for that particular type of
events has been enabled. Possible value
26 matches
Mail list logo
