Re: TSC timecounters

2017-10-07 Thread Adam Steen 
On Sun, Oct 8, 2017 at 6:03 AM, Theo de Raadt  wrote:

> > Adam will correct me if I'm wrong, but his idea was to provide clock
> > emulation to the operating system running in userland (solo5/unikernel).
> > Perhaps vmd can make use of this interface too.
>
> But why does it matter if it knows the frequency?
>

Hi Mike, Theo

yes, Mike you are correct.

To provide more background, quoting the solo5 readme[https://github.com/
Solo5/solo5], "Solo5 is most useful as a "base layer" to run MirageOS
unikernels, either on various existing hypervisors (KVM/QEMU, bhyve) or on
a specialized "unikernel monitor" called ukvm."

With the Help of Mike B and Mile L, i have been successfully running solo5
test kernels on ukvm (userland) and vmm (OpenBSD kernel) locally.

ukvm needs to know the tsc frequency, so it can pass this information to a
Solo5 unikernel which then uses rdtsc() to implement a clock.

the following links to source code provide some more information
solo5 unikernel clock implementation
https://github.com/Solo5/solo5/blob/f8a277f83807333685742228ffef0d
87270207cf/kernel/ukvm/tscclock.c#L60-L106

solo5 unikernel clock initialisation
https://github.com/Solo5/solo5/blob/9bad601c79ba7a549c87d22aaa970d
695e81e188/kernel/ukvm/time.c#L25
ukvm on OpenBSD setting up the tsc frequency
https://github.com/adamsteen/solo5/blob/master/ukvm/ukvm_
hv_openbsd_x86_64.c#L137
and

https://github.com/adamsteen/solo5/blob/200d7c4d4feb7aca62a3bae61f2ab1ec4bdd5bc9/ukvm/ukvm_hv_openbsd_x86_64.c#L52-L73





Cheers
Adam

Re: TSC timecounters

2017-10-07 Thread Theo de Raadt 
> Adam will correct me if I'm wrong, but his idea was to provide clock
> emulation to the operating system running in userland (solo5/unikernel).
> Perhaps vmd can make use of this interface too.

But why does it matter if it knows the frequency?

Re: TSC timecounters

2017-10-07 Thread Mike Belopuhov 
On Sat, Oct 07, 2017 at 17:23 +, Theo de Raadt wrote:
> > > > Now that we have an accurate tsc frequency, I would like to expose this
> > > > information to userland via a sysctl.
> > > >
> > > > The diff below exposes the tsc frequency and if it is invariant.
> > > >
> > > > Cheers,
> > > > Adam
> > > >
> > > >
> > > Please ignore that diff, looks like i had some dregs from a older diff i
> > > had been testing
> > 
> > Yeah, I've renamed a few things and deliberately skipped the sysctl part
> > so that we can test for regressions and don't mess with exposed interfaces
> > if we need to back out.  So I'd wait a few weeks for people to get it
> > running on a variety of systems and report the fallout if any.
> 
> The frequency can be found in dmesg.
> 
> Is there a particular reason why a piece of software has to query it
> with sysctl?  

Adam will correct me if I'm wrong, but his idea was to provide clock
emulation to the operating system running in userland (solo5/unikernel).
Perhaps vmd can make use of this interface too.

Re: TSC timecounters

2017-10-07 Thread Theo de Raadt 
> > > Now that we have an accurate tsc frequency, I would like to expose this
> > > information to userland via a sysctl.
> > >
> > > The diff below exposes the tsc frequency and if it is invariant.
> > >
> > > Cheers,
> > > Adam
> > >
> > >
> > Please ignore that diff, looks like i had some dregs from a older diff i
> > had been testing
> 
> Yeah, I've renamed a few things and deliberately skipped the sysctl part
> so that we can test for regressions and don't mess with exposed interfaces
> if we need to back out.  So I'd wait a few weeks for people to get it
> running on a variety of systems and report the fallout if any.

The frequency can be found in dmesg.

Is there a particular reason why a piece of software has to query it
with sysctl?

Re: TSC timecounters

2017-10-07 Thread Mike Belopuhov 
On Sat, Oct 07, 2017 at 10:27 +, Adam Steen wrote:
> On Sat, Oct 7, 2017 at 5:52 PM, Adam Steen  wrote:
> 
> > On Fri, Oct 06, 2017 at 03:58:18PM +0200, Mike Belopuhov wrote:
> > > Hi,
> > >
> > > An experimental change to use TSC as a timecounter source on a variety
> > > of modern Intel and AMD CPUs has been just committed and enabled on
> > > OpenBSD/amd64 thanks to the work done by Adam Steen.
> > >
> > > The rationale is, quoting the commit message:
> > >
> > >   If frequency of an invariant (non-stop) time stamp counter is measured
> > >   using an independent working timecounter that has a known frequency, we
> > >   can assume that the measured TSC frequency is as good as the resolution
> > >   of the timecounter that we use to perform the measurement. This lets us
> > >   switch from this high quality but expensive source to the cheaper TSC
> > >   without sacrificing precision on a wide range of modern CPUs.
> > >
> > > You can query and change the current timecounter source in the runtime
> > > via sysctl:
> > >
> > >   % sysctl kern.timecounter.{choice,hardware}
> > >   kern.timecounter.choice=i8254(0) tsc(2000) acpihpet0(1000)
> > acpitimer0(1000) dummy(-100)
> > >   kern.timecounter.hardware=tsc
> > >
> > > Please make sure your NTP drift (/var/db/ntpd.drift) stays within
> > -20..+20
> > > or at least is not worse than it is right now.
> > >
> > > And finally, please make sure to run a "make config" when building the
> > > kernel to update offset tables because of the cpu_info structure changes.
> > >
> > > Regards,
> > > Mike
> > >
> >
> > Hi,
> >
> > Now that we have an accurate tsc frequency, I would like to expose this
> > information to userland via a sysctl.
> >
> > The diff below exposes the tsc frequency and if it is invariant.
> >
> > Cheers,
> > Adam
> >
> >
> Please ignore that diff, looks like i had some dregs from a older diff i
> had been testing

Yeah, I've renamed a few things and deliberately skipped the sysctl part
so that we can test for regressions and don't mess with exposed interfaces
if we need to back out.  So I'd wait a few weeks for people to get it
running on a variety of systems and report the fallout if any.

ctan(3) NaN

2017-10-07 Thread Ingo Feinerer 
Hi,

I think I found a bug/inconsistency/regression in ctan(3) introduced
somewhere after 6.1 release. Originally observed in math/R
(https://marc.info/?l=openbsd-ports=150728711530471=2) the behavior can be
reproduced with following C program:

--8<---
#include 
#include 
#include 

int
main(int argc, char *argv[])
{
// http://en.cppreference.com/w/c/numeric/complex/ctan
double complex z = ctan(1);  // behaves like real tangent along the 
real line
printf("tan(1+0i) = %f%+fi ( tan(1)=%f)\n", creal(z), cimag(z), tan(1));

// http://en.cppreference.com/w/c/numeric/complex/ctan
double complex z2 = ctan(I); // behaves like tanh along the imaginary 
line
printf("tan(0+1i) = %f%+fi (tanh(1)=%f)\n", creal(z2), cimag(z2), 
tanh(1));

double complex z3 = ctan(1+1000I);
printf("tan(1+1000i) = %f%+fi\n", creal(z3), cimag(z3));
}
--8<---

cc ctan.c -lm
./a.out

The correct solution for the z3 example is "0+1i".

On a -current amd64 system (both clang and gcc give identical results):

$ ./a.out
tan(1+0i) = 1.557408+0.00i ( tan(1)=1.557408)
tan(0+1i) = 0.00+0.761594i (tanh(1)=0.761594)
tan(1+1000i) = -nan-nani

On 6.1 release amd64 with gcc 4.2.1:

$ ./a.out
tan(1+0i) = 1.557408+0.00i ( tan(1)=1.557408)
tan(0+1i) = 0.00+0.761594i (tanh(1)=0.761594)
tan(1+1000i) = 0.00-nani

This result seems to be "sufficiently different from wrong" that R is somehow
able to return the correct solution on 6.1 release:

R> (z <- tan(1+1000i))
[1] 0+1i

On a Debian 9.1 Linux with gcc 6.3.0:

$ ./a.out
tan(1+0i) = 1.557408+0.00i ( tan(1)=1.557408)
tan(0+1i) = 0.00+0.761594i (tanh(1)=0.761594)
tan(1+1000i) = 0.00+1.00i

Ideas, pointers and solutions are highly appreciated.

Best regards,
Ingo

Re: maxproc limits

2017-10-07 Thread Marc Espie 
On Fri, Oct 06, 2017 at 04:06:15PM +0100, Stuart Henderson wrote:
> I have been bumping into maxproc limits a lot recently on my
> workstation. While I do have quite a lot of processes at times, I don't
> think I have quite been tripping into the limits of number of actual
> processes.
> 
> It seems that perhaps threads are counted towards these. Is that
> expected/desirable? If so, would it be sane to raise the defaults
> in login.conf and NPROCESS? 1310 isn't a lot when chromium is
> using 500+.

Somewhat related, I think that pbuild defaults on amd64 should be bumped.
(lots of cpus, and enough address space to take advantage of it)

I regularly run into a few ports I have to restart because I ran into the
maxproc limits.

But then, 32 CPUs...

Re: TSC timecounters

2017-10-07 Thread Adam Steen 
On Sat, Oct 07, 2017 at 06:27:53PM +0800, Adam Steen wrote:
> On Sat, Oct 7, 2017 at 5:52 PM, Adam Steen  wrote:
> 
> > On Fri, Oct 06, 2017 at 03:58:18PM +0200, Mike Belopuhov wrote:
> > > Hi,
> > >
> > > An experimental change to use TSC as a timecounter source on a variety
> > > of modern Intel and AMD CPUs has been just committed and enabled on
> > > OpenBSD/amd64 thanks to the work done by Adam Steen.
> > >
> > > The rationale is, quoting the commit message:
> > >
> > >   If frequency of an invariant (non-stop) time stamp counter is measured
> > >   using an independent working timecounter that has a known frequency, we
> > >   can assume that the measured TSC frequency is as good as the resolution
> > >   of the timecounter that we use to perform the measurement. This lets us
> > >   switch from this high quality but expensive source to the cheaper TSC
> > >   without sacrificing precision on a wide range of modern CPUs.
> > >
> > > You can query and change the current timecounter source in the runtime
> > > via sysctl:
> > >
> > >   % sysctl kern.timecounter.{choice,hardware}
> > >   kern.timecounter.choice=i8254(0) tsc(2000) acpihpet0(1000)
> > acpitimer0(1000) dummy(-100)
> > >   kern.timecounter.hardware=tsc
> > >
> > > Please make sure your NTP drift (/var/db/ntpd.drift) stays within
> > -20..+20
> > > or at least is not worse than it is right now.
> > >
> > > And finally, please make sure to run a "make config" when building the
> > > kernel to update offset tables because of the cpu_info structure changes.
> > >
> > > Regards,
> > > Mike
> > >
> >
> > Hi,
> >
> > Now that we have an accurate tsc frequency, I would like to expose this
> > information to userland via a sysctl.
> >
> > The diff below exposes the tsc frequency and if it is invariant.
> >
> > Cheers,
> > Adam
> >
> >
> Please ignore that diff, looks like i had some dregs from a older diff i
> had been testing

Hi,

Take two, please see the diff below making tsc frequency and tsc is
invariant available to userland via a machdep sysctl.

I need to tsc frequency for my port of Solo5(ukvm) to OpenBSD vmm, the time
counter used by a solo5 is based on the tsc frequency.

Cheers
Adam

Index: sys/arch/amd64/amd64/machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/machdep.c,v
retrieving revision 1.231
diff -u -p -u -p -r1.231 machdep.c
--- sys/arch/amd64/amd64/machdep.c  12 Jul 2017 06:26:32 -  1.231
+++ sys/arch/amd64/amd64/machdep.c  7 Oct 2017 10:50:31 -
@@ -425,6 +425,8 @@ int
 cpu_sysctl(int *name, u_int namelen, void *oldp, size_t *oldlenp, void *newp,
 size_t newlen, struct proc *p)
 {
+   extern uint64_t tsc_frequency;
+   extern int  tsc_is_invariant;
extern int amd64_has_xcrypt;
dev_t consdev;
dev_t dev;
@@ -496,6 +498,12 @@ cpu_sysctl(int *name, u_int namelen, voi
pckbc_release_console();
return (error);
 #endif
+   case CPU_TSCFREQ:
+   return (sysctl_rdquad(oldp, oldlenp, newp,
+   tsc_frequency));
+   case CPU_INVARIANTTSC:
+   return (sysctl_rdint(oldp, oldlenp, newp,
+   tsc_is_invariant));
default:
return (EOPNOTSUPP);
}
Index: sys/arch/amd64/include/cpu.h
===
RCS file: /cvs/src/sys/arch/amd64/include/cpu.h,v
retrieving revision 1.115
diff -u -p -u -p -r1.115 cpu.h
--- sys/arch/amd64/include/cpu.h6 Oct 2017 13:33:53 -   1.115
+++ sys/arch/amd64/include/cpu.h7 Oct 2017 10:50:33 -
@@ -426,7 +426,9 @@ void mp_setperf_init(void);
 #define CPU_XCRYPT 12  /* supports VIA xcrypt in userland */
 #define CPU_LIDACTION  14  /* action caused by lid close */
 #define CPU_FORCEUKBD  15  /* Force ukbd(4) as console keyboard */
-#define CPU_MAXID  16  /* number of valid machdep ids */
+#define CPU_TSCFREQ16  /* tsc frequency */
+#define CPU_INVARIANTTSC   17  /* tsc is invariant */
+#define CPU_MAXID  18  /* number of valid machdep ids */
 
 #defineCTL_MACHDEP_NAMES { \
{ 0, 0 }, \
@@ -445,6 +447,8 @@ void mp_setperf_init(void);
{ 0, 0 }, \
{ "lidaction", CTLTYPE_INT }, \
{ "forceukbd", CTLTYPE_INT }, \
+   { "tscfreq", CTLTYPE_QUAD }, \
+   { "invarianttsc", CTLTYPE_INT }, \
 }
 
 /*

Re: TSC timecounters

2017-10-07 Thread Adam Steen 
On Sat, Oct 7, 2017 at 5:52 PM, Adam Steen  wrote:

> On Fri, Oct 06, 2017 at 03:58:18PM +0200, Mike Belopuhov wrote:
> > Hi,
> >
> > An experimental change to use TSC as a timecounter source on a variety
> > of modern Intel and AMD CPUs has been just committed and enabled on
> > OpenBSD/amd64 thanks to the work done by Adam Steen.
> >
> > The rationale is, quoting the commit message:
> >
> >   If frequency of an invariant (non-stop) time stamp counter is measured
> >   using an independent working timecounter that has a known frequency, we
> >   can assume that the measured TSC frequency is as good as the resolution
> >   of the timecounter that we use to perform the measurement. This lets us
> >   switch from this high quality but expensive source to the cheaper TSC
> >   without sacrificing precision on a wide range of modern CPUs.
> >
> > You can query and change the current timecounter source in the runtime
> > via sysctl:
> >
> >   % sysctl kern.timecounter.{choice,hardware}
> >   kern.timecounter.choice=i8254(0) tsc(2000) acpihpet0(1000)
> acpitimer0(1000) dummy(-100)
> >   kern.timecounter.hardware=tsc
> >
> > Please make sure your NTP drift (/var/db/ntpd.drift) stays within
> -20..+20
> > or at least is not worse than it is right now.
> >
> > And finally, please make sure to run a "make config" when building the
> > kernel to update offset tables because of the cpu_info structure changes.
> >
> > Regards,
> > Mike
> >
>
> Hi,
>
> Now that we have an accurate tsc frequency, I would like to expose this
> information to userland via a sysctl.
>
> The diff below exposes the tsc frequency and if it is invariant.
>
> Cheers,
> Adam
>
>
Please ignore that diff, looks like i had some dregs from a older diff i
had been testing

Re: TSC timecounters

2017-10-07 Thread Adam Steen 
On Fri, Oct 06, 2017 at 03:58:18PM +0200, Mike Belopuhov wrote:
> Hi,
> 
> An experimental change to use TSC as a timecounter source on a variety
> of modern Intel and AMD CPUs has been just committed and enabled on
> OpenBSD/amd64 thanks to the work done by Adam Steen.
> 
> The rationale is, quoting the commit message:
> 
>   If frequency of an invariant (non-stop) time stamp counter is measured
>   using an independent working timecounter that has a known frequency, we
>   can assume that the measured TSC frequency is as good as the resolution
>   of the timecounter that we use to perform the measurement. This lets us
>   switch from this high quality but expensive source to the cheaper TSC
>   without sacrificing precision on a wide range of modern CPUs.
> 
> You can query and change the current timecounter source in the runtime
> via sysctl:
> 
>   % sysctl kern.timecounter.{choice,hardware}
>   kern.timecounter.choice=i8254(0) tsc(2000) acpihpet0(1000) acpitimer0(1000) 
> dummy(-100)
>   kern.timecounter.hardware=tsc
> 
> Please make sure your NTP drift (/var/db/ntpd.drift) stays within -20..+20
> or at least is not worse than it is right now.
> 
> And finally, please make sure to run a "make config" when building the
> kernel to update offset tables because of the cpu_info structure changes.
> 
> Regards,
> Mike
> 

Hi,

Now that we have an accurate tsc frequency, I would like to expose this
information to userland via a sysctl.

The diff below exposes the tsc frequency and if it is invariant.

Cheers,
Adam

Index: sys/arch/amd64/amd64/machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/machdep.c,v
retrieving revision 1.231
diff -u -p -u -p -r1.231 machdep.c
--- sys/arch/amd64/amd64/machdep.c  12 Jul 2017 06:26:32 -  1.231
+++ sys/arch/amd64/amd64/machdep.c  7 Oct 2017 09:25:24 -
@@ -425,6 +425,8 @@ int
 cpu_sysctl(int *name, u_int namelen, void *oldp, size_t *oldlenp, void *newp,
 size_t newlen, struct proc *p)
 {
+   extern uint64_t amd64_tsc_frequency;
+   extern int amd64_has_invariant_tsc;
extern int amd64_has_xcrypt;
dev_t consdev;
dev_t dev;
@@ -496,6 +498,12 @@ cpu_sysctl(int *name, u_int namelen, voi
pckbc_release_console();
return (error);
 #endif
+   case CPU_TSCFREQ:
+   return (sysctl_rdquad(oldp, oldlenp, newp,
+   amd64_tsc_frequency));
+   case CPU_INVARIANTTSC:
+   return (sysctl_rdint(oldp, oldlenp, newp,
+   amd64_has_invariant_tsc));
default:
return (EOPNOTSUPP);
}
Index: sys/arch/amd64/include/cpu.h
===
RCS file: /cvs/src/sys/arch/amd64/include/cpu.h,v
retrieving revision 1.115
diff -u -p -u -p -r1.115 cpu.h
--- sys/arch/amd64/include/cpu.h6 Oct 2017 13:33:53 -   1.115
+++ sys/arch/amd64/include/cpu.h7 Oct 2017 09:25:26 -
@@ -426,7 +426,9 @@ void mp_setperf_init(void);
 #define CPU_XCRYPT 12  /* supports VIA xcrypt in userland */
 #define CPU_LIDACTION  14  /* action caused by lid close */
 #define CPU_FORCEUKBD  15  /* Force ukbd(4) as console keyboard */
-#define CPU_MAXID  16  /* number of valid machdep ids */
+#define CPU_TSCFREQ16  /* tsc frequency */
+#define CPU_INVARIANTTSC   17  /* has invariant tsc */
+#define CPU_MAXID  18  /* number of valid machdep ids */
 
 #defineCTL_MACHDEP_NAMES { \
{ 0, 0 }, \
@@ -445,6 +447,8 @@ void mp_setperf_init(void);
{ 0, 0 }, \
{ "lidaction", CTLTYPE_INT }, \
{ "forceukbd", CTLTYPE_INT }, \
+   { "tscfreq", CTLTYPE_QUAD }, \
+   { "invarianttsc", CTLTYPE_INT }, \
 }
 
 /*

drop __plt_{start,end} support

2017-10-07 Thread Philip Guenther 

Our ld hasn't generated __plt_{start,end} symbols for over a year, back in 
6.0, so it's time to kill support for them in ld.so.

(Where it matters, the need for the writable PLT is handled by
 a) marking it RWE which is automatically mapped as RW and then 
mprotect()ed to RX after relocation process, and
 b) kbind(2) permiting direct modification.)

ok?

I strongly suspect the --no-secureplt option to ld on alpha has been 
useless for this last year, given the lack of __plt_{start,end} handling 
in ld's default script, but I don't have a box to prove it.  If someone 
can confirm that then there's still more code that can be thrown in the 
chipper-shredder.



Index: alpha/rtld_machine.c
===
RCS file: /data/src/openbsd/src/libexec/ld.so/alpha/rtld_machine.c,v
retrieving revision 1.61
diff -u -p -r1.61 rtld_machine.c
--- alpha/rtld_machine.c16 Feb 2017 13:31:10 -  1.61
+++ alpha/rtld_machine.c9 Sep 2017 03:34:08 -
@@ -306,11 +306,6 @@ _dl_md_reloc_got(elf_object_t *object, i
_dl_protect_segment(object, seg_start, "__got_start", "__got_end",
PROT_READ);
 
-   /* mprotect the PLT, if it isn't already read-only */
-   if (pltro == 0)
-   _dl_protect_segment(object, (Elf_Addr)pltgot, "__plt_start",
-   "__plt_end", PROT_READ|PROT_EXEC);
-
return (fails);
 }
 
Index: powerpc/rtld_machine.c
===
RCS file: /data/src/openbsd/src/libexec/ld.so/powerpc/rtld_machine.c,v
retrieving revision 1.62
diff -u -p -r1.62 rtld_machine.c
--- powerpc/rtld_machine.c  24 Jan 2017 10:59:10 -  1.62
+++ powerpc/rtld_machine.c  9 Sep 2017 03:28:38 -
@@ -573,10 +573,6 @@ _dl_md_reloc_got(elf_object_t *object, i
if (prot_exec != 0 && got_addr != NULL)
_dl_syncicache(got_addr, 4);
 
-   /* mprotect the PLT */
-   _dl_protect_segment(object, 0, "__plt_start", "__plt_end",
-   PROT_READ|prot_exec);
-
return (fails);
 }
 
Index: sparc64/rtld_machine.c
===
RCS file: /data/src/openbsd/src/libexec/ld.so/sparc64/rtld_machine.c,v
retrieving revision 1.60
diff -u -p -r1.60 rtld_machine.c
--- sparc64/rtld_machine.c  28 Aug 2017 14:06:22 -  1.60
+++ sparc64/rtld_machine.c  9 Sep 2017 03:25:15 -
@@ -841,10 +841,6 @@ _dl_md_reloc_got(elf_object_t *object, i
if (object->traced)
lazy = 1;
 
-   /* temporarily make the PLT writable */
-   _dl_protect_segment(object, 0, "__plt_start", "__plt_end",
-   PROT_READ|PROT_WRITE);
-
if (!lazy) {
fails = _dl_md_reloc_all_plt(object);
} else {
@@ -856,10 +852,6 @@ _dl_md_reloc_got(elf_object_t *object, i
 
/* mprotect the GOT */
_dl_protect_segment(object, 0, "__got_start", "__got_end", PROT_READ);
-
-   /* mprotect the PLT */
-   _dl_protect_segment(object, 0, "__plt_start", "__plt_end",
-   PROT_READ|PROT_EXEC);
 
return (fails);
 }

Re: efiboot: Restore GOP mode on SetMode() failure

2017-10-07 Thread Klemens Nanni 
On Sat, Oct 07, 2017 at 01:15:40AM +, YASUOKA Masahiko wrote:
> Hi,
> 
> > See my updated diff for reusing the gopi struct, please.
> 
> ok, but the diff seems to be against wrong revision.  You seems to
> have other diffs, moving gop and gopi to global at least.
> 
> Can you send it entirely?
My bad, those were applied on top of other (unsubmitted) diffs such as
https://marc.info/?l=openbsd-tech=150437080106164

The following diff against the latest revision only includes the
`machine gop' bits as well as reusing/declaring gop(i) globally.

diff --git a/sys/arch/amd64/stand/efiboot/efiboot.c 
b/sys/arch/amd64/stand/efiboot/efiboot.c
index 7151e22a16a..ebf441b647e 100644
--- a/sys/arch/amd64/stand/efiboot/efiboot.c
+++ b/sys/arch/amd64/stand/efiboot/efiboot.c
@@ -60,7 +60,7 @@ static voidefi_memprobe_internal(void);
 static void efi_video_init(void);
 static void efi_video_reset(void);
 static EFI_STATUS
-efi_gop_setmode(EFI_GRAPHICS_OUTPUT *gop, int mode);
+efi_gop_setmode(int mode);
 EFI_STATUS  efi_main(EFI_HANDLE, EFI_SYSTEM_TABLE *);
 
 void (*run_i386)(u_long, u_long, int, int, int, int, int, int, int, int)
@@ -696,13 +696,17 @@ efi_com_putc(dev_t dev, int c)
  * {EFI_,}_ACPI_20_TABLE_GUID or EFI_ACPI_TABLE_GUID means
  * ACPI 2.0 or above.
  */
-static EFI_GUID acpi_guid = ACPI_20_TABLE_GUID;
-static EFI_GUID smbios_guid = SMBIOS_TABLE_GUID;
+static EFI_GUID acpi_guid = ACPI_20_TABLE_GUID;
+static EFI_GUID smbios_guid = SMBIOS_TABLE_GUID;
+static EFI_GRAPHICS_OUTPUT *gop;
+static EFI_GRAPHICS_OUTPUT_MODE_INFORMATION
+   *gopi;
+static int  efi_gopmode = -1;
 
 #defineefi_guidcmp(_a, _b) memcmp((_a), (_b), sizeof(EFI_GUID))
 
 static EFI_STATUS
-efi_gop_setmode(EFI_GRAPHICS_OUTPUT *gop, int mode)
+efi_gop_setmode(int mode)
 {
EFI_STATUS  status;
 
@@ -718,14 +722,9 @@ efi_makebootargs(void)
 {
int  i;
EFI_STATUS   status;
-   EFI_GRAPHICS_OUTPUT *gop;
-   EFI_GRAPHICS_OUTPUT_MODE_INFORMATION
-   *gopi;
bios_efiinfo_t   ei;
-   int  curmode, bestmode = -1;
+   int  curmode;
UINTNsz, gopsiz, bestsiz = 0;
-   EFI_GRAPHICS_OUTPUT_MODE_INFORMATION
-   *info;
 
memset(, 0, sizeof(ei));
/*
@@ -748,21 +747,24 @@ efi_makebootargs(void)
status = EFI_CALL(BS->LocateProtocol, _guid, NULL,
(void **));
if (!EFI_ERROR(status)) {
-   for (i = 0; i < gop->Mode->MaxMode; i++) {
-   status = EFI_CALL(gop->QueryMode, gop, i, , );
-   if (EFI_ERROR(status))
-   continue;
-   gopsiz = info->HorizontalResolution *
-   info->VerticalResolution;
-   if (gopsiz > bestsiz) {
-   bestmode = i;
-   bestsiz = gopsiz;
+   if (efi_gopmode < 0) {
+   for (i = 0; i < gop->Mode->MaxMode; i++) {
+   status = EFI_CALL(gop->QueryMode, gop,
+   i, , );
+   if (EFI_ERROR(status))
+   continue;
+   gopsiz = gopi->HorizontalResolution *
+   gopi->VerticalResolution;
+   if (gopsiz > bestsiz) {
+   efi_gopmode = i;
+   bestsiz = gopsiz;
+   }
}
}
-   if (bestmode >= 0) {
+   if (efi_gopmode >= 0 && efi_gopmode != gop->Mode->Mode) {
curmode = gop->Mode->Mode;
-   if (efi_gop_setmode(gop, bestmode) != EFI_SUCCESS)
-   (void)efi_gop_setmode(gop, curmode);
+   if (efi_gop_setmode(efi_gopmode) != EFI_SUCCESS)
+   (void)efi_gop_setmode(curmode);
}
 
gopi = gop->Mode->Info;
@@ -884,3 +886,43 @@ Xpoweroff_efi(void)
EFI_CALL(RS->ResetSystem, EfiResetShutdown, EFI_SUCCESS, 0, NULL);
return (0);
 }
+
+int
+Xgop_efi(void)
+{
+   EFI_STATUS  status;
+   int i, mode = -1;
+   UINTN   sz;
+
+   status = EFI_CALL(BS->LocateProtocol, _guid, NULL,
+   (void **));
+   if (EFI_ERROR(status))
+   return (0);
+
+   if (cmd.argc >= 2) {
+   mode = strtol(cmd.argv[1], NULL, 10);
+   if (0 <= mode && mode < gop->Mode->MaxMode) {
+   status = EFI_CALL(gop->QueryMode, gop,

ofw_clock: reset_deassert and clock_enable order of use Qs

2017-10-07 Thread Artturi Alm 
Hi,


what was the cause of these delays? i just spotted this, so untested on
likely more affected HW(sunxi A64/H3 and rockchips), but just for discussion
about the delays/ordering? are they really needed like that?

i don't remember having read anything about the order of these from
devicetree-binding .txt's i have read so far from u-boot/linux.

"Make sure that the reset signal has been released
before the release of module clock gating;"

above can be found from under the short CCU "x.3.6 Programming Guidelines"[0].
maybe this ordering should be verified from somewhere else, as atleast
for my sorry non-nativeNlazy grammar i could understand wrong, what is being
meant w/"the release" above.. but even w/above discarded, my intuition does
favor deasserting reset before gating sclki, hence the diff.

the diff below booted faster with no observable changes in dmesg on cubie2,
and otherwise succesfully on panda and wandboard.

-Artturi

[0] sources:
A64 User Manual(Revision 1.0):
"3.3.6.4. Gating and reset" Page 147
H3 Datasheet(Revision1.2):
"4.3.6.4. Gating and reset" Page 142



diff --git a/sys/dev/fdt/ehci_fdt.c b/sys/dev/fdt/ehci_fdt.c
index 55fe75f1a9c..fae54ac11ee 100644
--- a/sys/dev/fdt/ehci_fdt.c
+++ b/sys/dev/fdt/ehci_fdt.c
@@ -91,9 +91,10 @@ ehci_fdt_attach(struct device *parent, struct device *self, 
void *aux)
 
pinctrl_byname(sc->sc_node, "default");
 
-   clock_enable_all(sc->sc_node);
reset_deassert_all(sc->sc_node);
 
+   clock_enable_all(sc->sc_node);
+
/* Disable interrupts, so we don't get any spurious ones. */
sc->sc.sc_offs = EREAD1(>sc, EHCI_CAPLENGTH);
EOWRITE2(>sc, EHCI_USBINTR, 0);
diff --git a/sys/dev/fdt/if_dwge_fdt.c b/sys/dev/fdt/if_dwge_fdt.c
index edfe5acb992..00668980f4a 100644
--- a/sys/dev/fdt/if_dwge_fdt.c
+++ b/sys/dev/fdt/if_dwge_fdt.c
@@ -125,10 +125,10 @@ dwge_fdt_attach(struct device *parent, struct device 
*self, void *aux)
else if (OF_is_compatible(faa->fa_node, "rockchip,rk3399-gmac"))
dwge_fdt_attach_rockchip(fsc);
 
+   reset_deassert(faa->fa_node, "stmmaceth");
+
/* Enable clock. */
clock_enable(faa->fa_node, "stmmaceth");
-   reset_deassert(faa->fa_node, "stmmaceth");
-   delay(5000);
 
/* Power up PHY. */
phy_supply = OF_getpropint(faa->fa_node, "phy-supply", 0);
diff --git a/sys/dev/fdt/if_dwxe.c b/sys/dev/fdt/if_dwxe.c
index 22a383c06ef..6e303745ec3 100644
--- a/sys/dev/fdt/if_dwxe.c
+++ b/sys/dev/fdt/if_dwxe.c
@@ -376,10 +376,10 @@ dwxe_attach(struct device *parent, struct device *self, 
void *aux)
 
pinctrl_byname(faa->fa_node, "default");
 
+   reset_deassert(faa->fa_node, "stmmaceth");
+
/* Enable clock. */
clock_enable(faa->fa_node, "stmmaceth");
-   reset_deassert(faa->fa_node, "stmmaceth");
-   delay(5000);
 
/* Power up PHY. */
phy_supply = OF_getpropint(faa->fa_node, "phy-supply", 0);
diff --git a/sys/dev/fdt/sximmc.c b/sys/dev/fdt/sximmc.c
index 7acb8f55d56..9ed2ae09fe4 100644
--- a/sys/dev/fdt/sximmc.c
+++ b/sys/dev/fdt/sximmc.c
@@ -366,11 +366,10 @@ sximmc_attach(struct device *parent, struct device *self, 
void *aux)
 
pinctrl_byname(faa->fa_node, "default");
 
+   reset_deassert_all(faa->fa_node);
+
/* enable clock */
clock_enable(faa->fa_node, NULL);
-   delay(5000);
-
-   reset_deassert_all(faa->fa_node);
 
/*
 * The FIFO register is in a different location on the
diff --git a/sys/dev/fdt/sxitwi.c b/sys/dev/fdt/sxitwi.c
index f53f2bfd594..c80bdc2ab06 100644
--- a/sys/dev/fdt/sxitwi.c
+++ b/sys/dev/fdt/sxitwi.c
@@ -218,6 +218,8 @@ sxitwi_attach(struct device *parent, struct device *self, 
void *aux)
 
pinctrl_byname(faa->fa_node, "default");
 
+   reset_deassert_all(faa->fa_node);
+
/* Enable clock */
clock_enable(faa->fa_node, NULL);

smtpd: prefer clock_gettime()

2017-10-07 Thread Philip Guenther 

...over gettimeofday()+TIMEVAL_TO_TIMESPEC()

Note that smtpd already uses clock_gettime() so this isn't an issue for 
-portable.

ok?

Index: smtpd/queue_fs.c
===
RCS file: /data/src/openbsd/src/usr.sbin/smtpd/queue_fs.c,v
retrieving revision 1.14
diff -u -p -r1.14 queue_fs.c
--- smtpd/queue_fs.c30 Dec 2015 11:40:30 -  1.14
+++ smtpd/queue_fs.c4 Feb 2017 08:45:46 -
@@ -729,7 +729,6 @@ queue_fs_init(struct passwd *pw, int ser
char*paths[] = { PATH_QUEUE, PATH_CORRUPT, PATH_INCOMING };
char path[PATH_MAX];
int  ret;
-   struct timeval   tv;
 
/* remove incoming/ if it exists */
if (server)
@@ -746,9 +745,8 @@ queue_fs_init(struct passwd *pw, int ser
ret = 0;
}
 
-   if (gettimeofday(, NULL) == -1)
-   err(1, "gettimeofday");
-   TIMEVAL_TO_TIMESPEC(, );
+   if (clock_gettime(CLOCK_REALTIME, ))
+   err(1, "clock_gettime");
 
tree_init();