Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Noth]

On 02/20/16 06:46, Theo de Raadt wrote:

I'm using VAIO Z.  Hibernation works, but my vaio also wakes back
immediately.  I have a diff to avoid this wakeup.  Unhibernation works
fine.

The diff seems very bad. :)

Index: sys/dev/acpi/acpi.c
===
RCS file: /disk/cvs/openbsd/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.303
diff -u -p -r1.303 acpi.c
--- sys/dev/acpi/acpi.c 14 Jan 2016 21:37:18 -  1.303
+++ sys/dev/acpi/acpi.c 21 Jan 2016 08:25:59 -
@@ -2048,6 +2048,7 @@ acpi_enable_wakegpes(struct acpi_softc *
  {
struct acpi_wakeq *wentry;
  
+return;

SIMPLEQ_FOREACH(wentry, >sc_wakedevs, q_next) {
dnprintf(10, "%.4s(S%d) gpe %.2x\n", wentry->q_node->name,
wentry->q_state,

That is a very interesting diff.  Mike will probably remember this.
Was it Berlin?  I think sebastia's Viao had a quirk where a wakeup gpe
was doing something wrong.

That will assuredly break most thinkpads :)




That patch works for me, thank you Masahiko. Looks like OpenBSD runs 
pretty well on this little laptop :)

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Theo de Raadt]

> I'm using VAIO Z.  Hibernation works, but my vaio also wakes back
> immediately.  I have a diff to avoid this wakeup.  Unhibernation works
> fine.
> 
> The diff seems very bad. :)
> 
> Index: sys/dev/acpi/acpi.c
> ===
> RCS file: /disk/cvs/openbsd/src/sys/dev/acpi/acpi.c,v
> retrieving revision 1.303
> diff -u -p -r1.303 acpi.c
> --- sys/dev/acpi/acpi.c   14 Jan 2016 21:37:18 -  1.303
> +++ sys/dev/acpi/acpi.c   21 Jan 2016 08:25:59 -
> @@ -2048,6 +2048,7 @@ acpi_enable_wakegpes(struct acpi_softc *
>  {
>   struct acpi_wakeq *wentry;
>  
> +return;
>   SIMPLEQ_FOREACH(wentry, >sc_wakedevs, q_next) {
>   dnprintf(10, "%.4s(S%d) gpe %.2x\n", wentry->q_node->name,
>   wentry->q_state,

That is a very interesting diff.  Mike will probably remember this.
Was it Berlin?  I think sebastia's Viao had a quirk where a wakeup gpe
was doing something wrong.

That will assuredly break most thinkpads :)

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[YASUOKA Masahiko]

On Sat, 20 Feb 2016 04:17:05 +0100
Noth  wrote:
>   I installed -CURRENT on my laptop today, so far so good on the UEFI
>   boot, crypto disk and wifi with .11n. Unfortunately the suspend to ram
>   and hibernate options don't work... Suspend goes to suspend but wakes
>   back immediately and freezes, hibernate goes to a black screen and
>   freezes. I've got apmd running with -C.  I've included the acpidump
>   and hope it will help with any debugging.

I'm using VAIO Z.  Hibernation works, but my vaio also wakes back
immediately.  I have a diff to avoid this wakeup.  Unhibernation works
fine.

The diff seems very bad. :)

Index: sys/dev/acpi/acpi.c
===
RCS file: /disk/cvs/openbsd/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.303
diff -u -p -r1.303 acpi.c
--- sys/dev/acpi/acpi.c 14 Jan 2016 21:37:18 -  1.303
+++ sys/dev/acpi/acpi.c 21 Jan 2016 08:25:59 -
@@ -2048,6 +2048,7 @@ acpi_enable_wakegpes(struct acpi_softc *
 {
struct acpi_wakeq *wentry;
 
+return;
SIMPLEQ_FOREACH(wentry, >sc_wakedevs, q_next) {
dnprintf(10, "%.4s(S%d) gpe %.2x\n", wentry->q_node->name,
wentry->q_state,

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Noth]

Hello again

On 02/20/16 06:23, Jack J. Woehr wrote:

Theo de Raadt wrote:


That's not very helpful.
My apologies. If you follow the thread 
https://marc.info/?l=openbsd-misc=144761680226242=2 you'll see 
that I reported
a similar problem on my own VAIO and was given a workaround that 
amounted to the same answer I gave, except that I gave my
answer wittily, I thought at the time, and offhand after a 12-hour day 
of work.


Long live OpenBSD.



Ok, if I disable xhci in UKC, suspend works. Hibernate doesn't but then 
that doesn't matter too much to me. Thanks for the suggestion Theo!


Noth

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Jack J. Woehr]

Theo de Raadt wrote:


That's not very helpful.

My apologies. If you follow the thread 
https://marc.info/?l=openbsd-misc=144761680226242=2 you'll see that I 
reported
a similar problem on my own VAIO and was given a workaround that amounted to 
the same answer I gave, except that I gave my
answer wittily, I thought at the time, and offhand after a 12-hour day of work.

Long live OpenBSD.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Theo de Raadt]

> On Fri, Feb 19, 2016 at 09:41:59PM -0700, Jack J. Woehr wrote:
> > Noth wrote:
> > >Unfortunately the suspend to ram and hibernate options don't work
> > They don't. Proprietary undocumented hardware. "Doctor, it hurts when I do 
> > this." "Don't do that."
> 
> That's not very helpful.

Indeed, it is becoming quite depressing that some people who act like
our fan club can so quickly attack new users who submit good bug
reports in their very first email, for hardware they happen to have.
For hardware which we do struggle to support, if only we had such
reports on a regular basis.

Jack, consider taking a break from the list if that is your approach.

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Bryan Steele]

On Fri, Feb 19, 2016 at 09:41:59PM -0700, Jack J. Woehr wrote:
> Noth wrote:
> >Unfortunately the suspend to ram and hibernate options don't work
> They don't. Proprietary undocumented hardware. "Doctor, it hurts when I do 
> this." "Don't do that."

That's not very helpful.

> Noth wrote:
> >Unfortunately the suspend to ram and hibernate options don't work

At least on some systems, disabling TPM and related security features in
the BIOS options may fix some suspend/hibernate issues.

Re: Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Jack J. Woehr]

Noth wrote:

Unfortunately the suspend to ram and hibernate options don't work

They don't. Proprietary undocumented hardware. "Doctor, it hurts when I do this." 
"Don't do that."

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

Vaio Pro 11" SVP112A1CL can't suspend to ram or hibernate

[Noth]

Hi tech@

  I installed -CURRENT on my laptop today, so far so good on the UEFI 
boot, crypto disk and wifi with .11n. Unfortunately the suspend to ram 
and hibernate options don't work... Suspend goes to suspend but wakes 
back immediately and freezes, hibernate goes to a black screen and 
freezes. I've got apmd running with -C.  I've included the acpidump and 
hope it will help with any debugging.


Cheers,

Noth

OpenBSD 5.9 (GENERIC.MP) #1870: Mon Feb  8 17:34:23 MST 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8475893760 (8083MB)
avail mem = 8214822912 (7834MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdbeb3018 (20 entries)
bios0: vendor American Megatrends Inc. version "R1044V7" date 03/24/2014
bios0: Sony Corporation SVP112190X
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT TCPA MSDM MCFG HPET SSDT SSDT PCCT 
SSDT SSDT SSDT SSDT SSDT SLIC ECDT BGRT SSDT
acpi0: wakeup devices PXSX(S4) RP05(S4) PXSX(S4) RP01(S4) PXSX(S4) 
RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) EHC1(S3) XHC_(S3) HDEF(S4) 
PWRB(S4)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 2694.27 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT

cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 2693.77 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT

cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 2693.77 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT

cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz, 2693.77 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT

cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS

acpitz0 at acpi0: critical temperature is 97 degC
acpibat0 at acpi0: BAT0 type LiOn oem "Sony Corp."
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 2694 MHz: speeds: 1801, 1800, 1700, 1600, 1500, 
1400, 1300, 1200, 1100, 1000, 900, 800 MHz

pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 4G Host" rev 0x09
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x09
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 1920x1080
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
azalia0 at pci0 dev 3 function 0 "Intel Core 4G HD Audio" rev 0x09: msi
xhci0 at pci0 dev 20 function 0 "Intel 8 Series xHCI" rev 0x04: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 

Re: Document the sendsyslog2(2) system call

[Theo de Raadt]

> The sendsyslog2 should be renamed to sendsyslog so that we only
> have to maintian one interface.  But this will not happen before
> OpenBSD 5.9 release.

Correct.

> So I think we should document the current situation and adapt the
> man page again when we remove the obsolete system call.

I wouldn't mind documenting it fully, but don't install the extra
manual page link.  Soon after 5.9 unlocks, it won't be installed.

Re: Document the sendsyslog2(2) system call

[Alexander Bluhm]

On Thu, Feb 18, 2016 at 03:48:46PM -0700, Rafael Neves wrote:
> Hi,
> 
> The the inlined patch aims to document the new sendsyslog2 system call,
> and add the corresponding MLINKS entry. Note that I do not put
> "syslog(3) logopt LOG_CONS" or "syslog(3) LOG_CONS flag" because
> actually in syslog(3) it says that it redirects to "/dev/console", so I
> thought that could be misleading as sendsyslog2(2) does not open the
> device, it is a direct channel.
> 
> Comments?

The sendsyslog2 should be renamed to sendsyslog so that we only
have to maintian one interface.  But this will not happen before
OpenBSD 5.9 release.

So I think we should document the current situation and adapt the
man page again when we remove the obsolete system call.

bluhm

> 
> 
> Regards,
> Rafael Neves
> 
> 
> Patch:
> 
> Index: lib/libc/sys/Makefile.inc
> ===
> RCS file: /cvs/src/lib/libc/sys/Makefile.inc,v
> retrieving revision 1.137
> diff -u -p -r1.137 Makefile.inc
> --- lib/libc/sys/Makefile.inc 25 Nov 2015 00:01:21 -  1.137
> +++ lib/libc/sys/Makefile.inc 18 Feb 2016 21:31:31 -
> @@ -224,6 +224,7 @@ MLINKS+=select.2 pselect.2
>  MLINKS+=select.2 FD_ISSET.3 select.2 FD_ZERO.3
>  MLINKS+=select.2 FD_SET.3 select.2 FD_CLR.3
>  MLINKS+=send.2 sendmsg.2 send.2 sendto.2
> +MLINKS+=sendsyslog.2 sendsyslog2.2
>  MLINKS+=setpgid.2 setpgrp.2
>  MLINKS+=setresuid.2 getresgid.2 setresuid.2 getresuid.2
>  MLINKS+=setresuid.2 setresgid.2
> Index: lib/libc/sys/sendsyslog.2
> ===
> RCS file: /cvs/src/lib/libc/sys/sendsyslog.2,v
> retrieving revision 1.4
> diff -u -p -r1.4 sendsyslog.2
> --- lib/libc/sys/sendsyslog.2 10 Sep 2015 17:55:21 -  1.4
> +++ lib/libc/sys/sendsyslog.2 18 Feb 2016 21:31:31 -
> @@ -18,19 +18,40 @@
>  .Dt SENDSYSLOG 2
>  .Os
>  .Sh NAME
> -.Nm sendsyslog
> +.Nm sendsyslog ,
> +.Nm sendsyslog2
>  .Nd send a message to syslogd
>  .Sh SYNOPSIS
> +.In sys/syslog.h
>  .In sys/types.h
>  .Ft int
>  .Fn sendsyslog "const void *msg" "size_t len"
> +.Ft int
> +.Fn sendsyslog2 "const void *msg" "size_t len" "int flags"
>  .Sh DESCRIPTION
> +.Pp
> +The
>  .Fn sendsyslog
> -is used to transmit a
> +and
> +.Fn sendsyslog2
> +functions are used to transmit a
>  .Xr syslog 3
>  formatted message direct to
>  .Xr syslogd 8
>  without requiring the allocation of a socket.
> +.Pp
> +The
> +.Fa flags
> +argument of
> +.Fn sendsyslog2
> +accepts the
> +.Dv LOG_CONS
> +flag. If 
> +.Dv LOG_CONS
> +is specified, and
> +.Xr syslogd 8
> +is not accepting messages, the message will be sent directly to the
> +console.
>  This is used internally by
>  .Xr syslog_r 3 ,
>  so that messages can be sent during difficult situations.
> @@ -41,7 +62,9 @@ so that messages can be sent during diff
>  can fail if:
>  .Bl -tag -width Er
>  .It Bq Er ENOTCONN
> -The message cannot be sent, likely because
> +The message cannot be sent to 
> +.Xr syslogd(8) ,
> +likely because
>  .Xr syslogd 8
>  is not running.
>  .El
> @@ -53,3 +76,7 @@ The
>  .Fn sendsyslog
>  function call appeared in
>  .Ox 5.6 .
> +The
> +.Fn sendsyslog2
> +function call appeared in
> +.Ox 5.9 .

Re: socppc/fdt: broken end signature check

[Patrick Wildt]

On Sat, Feb 20, 2016 at 01:32:20AM +0100, Patrick Wildt wrote:
> Hi,
> 
> there seems to be a broken check in socppc's fdt code.  I think this
> should not be a binary AND.
> 
> I have no hardware to verify that diff.
> 
> Patrick
> 
> diff --git sys/arch/socppc/socppc/fdt.c sys/arch/socppc/socppc/fdt.c
> index 9dae7e2..7423988 100644
> --- sys/arch/socppc/socppc/fdt.c
> +++ sys/arch/socppc/socppc/fdt.c
> @@ -58,7 +58,7 @@ fdt_check_head(void *fdt)
>   return 0;
>  
>   /* check for end signature on version 17 blob */
> - if ((fh->fh_version >= 17) & (*(ptr + fh->fh_struct_size) != FDT_END))
> + if ((fh->fh_version >= 17) && (*(ptr + fh->fh_struct_size) != FDT_END))
>   return 0;
>  
>   return fh->fh_version;

Also I'm fairly certain this check is not correct.  It stops my
not-socppc machine from booting up.

Something like

if ((fh->fh_version >= 17) && (*(ptr + (fh->fh_struct_size / 4)) != 
FDT_END))

might be better in theory, but still doesn't work on my machine.

socppc/fdt: convert big endian to host endian

[Patrick Wildt]

Hi,

FDT is spread widely in the embedded market.  Especially those ARM
machines make heavy use of it.  FDT is always stored in big endian,
like socppc.  To be able to use this code on little endian machines,
like those ARMs, this diff modifies the code to convert the binary
data from big endian to host endian.

This diff implements it, works on my little endian hardware and is
based on the previously sent diffs.

I have no socppc hardware to verify this diff.

Patrick

diff --git sys/arch/socppc/socppc/fdt.c sys/arch/socppc/socppc/fdt.c
index 6f30a85..cf3327b 100644
--- sys/arch/socppc/socppc/fdt.c
+++ sys/arch/socppc/socppc/fdt.c
@@ -48,20 +48,22 @@ fdt_check_head(void *fdt)
fh = fdt;
ptr = (u_int32_t *)fdt;
 
-   if (fh->fh_magic != FDT_MAGIC)
+   if (betoh32(fh->fh_magic) != FDT_MAGIC)
return 0;
 
-   if (fh->fh_version > FDT_CODE_VERSION)
+   if (betoh32(fh->fh_version) > FDT_CODE_VERSION)
return 0;
 
-   if (*(ptr + (fh->fh_struct_off / 4)) != FDT_NODE_BEGIN)
+   if (betoh32(*(ptr + (betoh32(fh->fh_struct_off) / 4)))
+   != FDT_NODE_BEGIN)
return 0;
 
/* check for end signature on version 17 blob */
-   if ((fh->fh_version >= 17) && (*(ptr + fh->fh_struct_size) != FDT_END))
+   if ((betoh32(fh->fh_version) >= 17) &&
+   (betoh32(*(ptr + betoh32(fh->fh_struct_size))) != FDT_END))
return 0;
 
-   return fh->fh_version;
+   return betoh32(fh->fh_version);
 }
 
 /*
@@ -83,11 +85,11 @@ fdt_init(void *fdt)
return 0;
 
tree.header = (struct fdt_head *)fdt;
-   tree.tree = (char *)fdt + tree.header->fh_struct_off;
-   tree.strings = (char *)fdt + tree.header->fh_strings_off;
-   tree.memory = (char *)fdt + tree.header->fh_reserve_off;
+   tree.tree = (char *)fdt + betoh32(tree.header->fh_struct_off);
+   tree.strings = (char *)fdt + betoh32(tree.header->fh_strings_off);
+   tree.memory = (char *)fdt + betoh32(tree.header->fh_reserve_off);
tree.version = version;
-   tree.strings_size = tree.header->fh_strings_size;
+   tree.strings_size = betoh32(tree.header->fh_strings_size);
tree_inited = 1;
 
return version;
@@ -112,7 +114,7 @@ skip_property(u_int32_t *ptr)
 {
u_int32_t size;
 
-   size = *(ptr + 1);
+   size = betoh32(*(ptr + 1));
/* move forward by magic + size + nameid + rounded up property size */
ptr += 3 + roundup(size, sizeof(u_int32_t)) / sizeof(u_int32_t);
 
@@ -122,7 +124,7 @@ skip_property(u_int32_t *ptr)
 void *
 skip_props(u_int32_t *ptr)
 {
-   while (*ptr == FDT_PROPERTY) {
+   while (betoh32(*ptr) == FDT_PROPERTY) {
ptr = skip_property(ptr);
}
return ptr;
@@ -152,17 +154,17 @@ fdt_node_property(void *node, char *name, char **out)
 
ptr = (u_int32_t *)node;
 
-   if (*ptr != FDT_NODE_BEGIN)
+   if (betoh32(*ptr) != FDT_NODE_BEGIN)
return 0;
 
ptr = skip_node_name(ptr + 1);
 
-   while (*ptr == FDT_PROPERTY) {
-   nameid = *(ptr + 2); /* id of name in strings table */
+   while (betoh32(*ptr) == FDT_PROPERTY) {
+   nameid = betoh32(*(ptr + 2)); /* id of name in strings table */
tmp = fdt_get_str(nameid);
if (!strcmp(name, tmp)) {
*out = (char *)(ptr + 3); /* beginning of the value */
-   return *(ptr + 1); /* size of value */
+   return betoh32(*(ptr + 1)); /* size of value */
}
ptr = skip_property(ptr);
}
@@ -185,10 +187,10 @@ fdt_next_node(void *node)
 
if (!node) {
ptr = tree.tree;
-   return (*ptr == FDT_NODE_BEGIN) ? ptr : NULL;
+   return (betoh32(*ptr) == FDT_NODE_BEGIN) ? ptr : NULL;
}
 
-   if (*ptr != FDT_NODE_BEGIN)
+   if (betoh32(*ptr) != FDT_NODE_BEGIN)
return NULL;
 
ptr++;
@@ -197,10 +199,10 @@ fdt_next_node(void *node)
ptr = skip_props(ptr);
 
/* skip children */
-   while (*ptr == FDT_NODE_BEGIN)
+   while (betoh32(*ptr) == FDT_NODE_BEGIN)
ptr = fdt_next_node(ptr);
 
-   return (*ptr == FDT_NODE_END) ? (ptr + 1) : NULL;
+   return (betoh32(*ptr) == FDT_NODE_END) ? (ptr + 1) : NULL;
 }
 
 /*
@@ -216,7 +218,7 @@ fdt_child_node(void *node)
 
ptr = node;
 
-   if (*ptr != FDT_NODE_BEGIN)
+   if (betoh32(*ptr) != FDT_NODE_BEGIN)
return NULL;
 
ptr++;
@@ -224,7 +226,7 @@ fdt_child_node(void *node)
ptr = skip_node_name(ptr);
ptr = skip_props(ptr);
/* check if there is a child node */
-   return (*ptr == FDT_NODE_BEGIN) ? (ptr) : NULL;
+   return (betoh32(*ptr) == FDT_NODE_BEGIN) ? (ptr) : NULL;
 }
 
 /*
@@ -240,7 +242,7 @@ fdt_node_name(void *node)
 
ptr = node;
 
-   

Re: [PATCH] No comic sans in httpd status pages

[Jiri B]

Instead of hipster design headache, there's for example this diff
which could bring something interesting to httpd

http://marc.info/?l=openbsd-tech=144767899506855=2

(httpd URL rewrite support patch)

Something like this could make wordpress, drupal, mediawiki
users more happy with OpenBSD httpd.

j.

socppc/fdt: useless code in fdt init

[Patrick Wildt]

Hi,

in socppc's fdt init code there's a path that is always run but never
produces anything valid, as it's overridden directly after.

tree.strings_size is always set to fh_strings_size at the end. So in
reality that whole version block might run, but in the end is completely
useless.  As no one has found that yet, I think it's safe to just get rid
of that whole block.  I'd also be fine with keeping the block and just
removing that assignment at the end.

I have no hardware to verify it.

Patrick

diff --git sys/arch/socppc/socppc/fdt.c sys/arch/socppc/socppc/fdt.c
index 7423988..6f30a85 100644
--- sys/arch/socppc/socppc/fdt.c
+++ sys/arch/socppc/socppc/fdt.c
@@ -87,25 +87,6 @@ fdt_init(void *fdt)
tree.strings = (char *)fdt + tree.header->fh_strings_off;
tree.memory = (char *)fdt + tree.header->fh_reserve_off;
tree.version = version;
-
-   if (version < 3) {
-   if ((tree.strings < tree.tree) && (tree.tree < tree.memory))
-   tree.strings_size = tree.tree - tree.strings;
-   else if ((tree.strings < tree.memory) && (tree.memory <
-   tree.tree))
-   tree.strings_size = tree.memory - tree.strings;
-   else if ((tree.strings < tree.tree) && (tree.memory <
-   tree.strings))
-   tree.strings_size = tree.tree - tree.strings;
-   else if ((tree.strings < tree.memory) && (tree.tree <
-   tree.strings))
-   tree.strings_size = tree.memory - tree.strings;
-   else
-   tree.strings_size = tree.header->fh_size -
-   (int)tree.strings;
-   } else
-   tree.strings_size = tree.header->fh_strings_size;
-
tree.strings_size = tree.header->fh_strings_size;
tree_inited = 1;
 

socppc/fdt: broken end signature check

[Patrick Wildt]

Hi,

there seems to be a broken check in socppc's fdt code.  I think this
should not be a binary AND.

I have no hardware to verify that diff.

Patrick

diff --git sys/arch/socppc/socppc/fdt.c sys/arch/socppc/socppc/fdt.c
index 9dae7e2..7423988 100644
--- sys/arch/socppc/socppc/fdt.c
+++ sys/arch/socppc/socppc/fdt.c
@@ -58,7 +58,7 @@ fdt_check_head(void *fdt)
return 0;
 
/* check for end signature on version 17 blob */
-   if ((fh->fh_version >= 17) & (*(ptr + fh->fh_struct_size) != FDT_END))
+   if ((fh->fh_version >= 17) && (*(ptr + fh->fh_struct_size) != FDT_END))
return 0;
 
return fh->fh_version;

Re: Enabling audio Realtek ALC1150

[Jonathan Gray]

On Fri, Feb 19, 2016 at 11:17:30PM +0100, Alexandre H wrote:
> Hello
> 
> The diffs were not completely commited...
> I have sent some diffs for three elements :
> pcidevs, azalia.c and azalia_codec.c
> 
> But the diff for azalia.c has not been commited.
> Without this diff, the PCI config. is not done and so the chip doesn't
> work, this diff is mandatory.
> So I resend all the diffs followed by a dmesg from 5.8-release.

Thanks, snooping now enabled for C600 and C610 HDA.

Re: [PATCH] No comic sans in httpd status pages

[Michael Jarvis]

I like the idea of just being able to specify a page to use for HTTP
error codes.  If nobody beats me to it, I plan on taking a crack at
implementing that feature, for my own use if nothing else.

In the mean time, I've done something similar to this patch, but I
used monospace as the font. I also removed the "style" variable, used
for the CSS snippet, since I don't think it adds anything to a
bare-bones "404" page. 

The nginx syntax seems reasonable, and putting a similar directive
in the httpd.conf file would work fine in my opinion.

Example:

error_page 404 /404.html

The hard-coded version could remain as the default. 


On Fri, Feb 19, 2016, at 16:29, Stuart Henderson wrote:
> On 2016/02/19 21:51, Peter Krantz wrote:
> > 
> > > 19 feb. 2016 kl. 17:49 skrev Luis Coronado :
> > > 
> > > I believe this was intentional from the beginning: 
> > > http://www.openbsd.org/papers/bsdcan14-libressl/mgp00025.html
> > 
> > Yeah, I figured. Nobody uses Comic Sans unintentionally :-)
> > 
> > Smart quotes and hurry killed the previous patch. This one works better as 
> > ammunition in dialogue with  sysadmins. 
> 
> Probably too late for 5.9 but wouldn't it be better to use a separate
> file for this like bgplg does? Then people can paint their own bikeshed
> without recompiling or imposing their aesthetics on others.
> 
> > 
> > ? no_comic_sans_in_404.patch
> > Index: server_http.c
> > ===
> > RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
> > retrieving revision 1.105
> > diff -u -r1.105 server_http.c
> > --- server_http.c   11 Feb 2016 19:30:04 -  1.105
> > +++ server_http.c   19 Feb 2016 20:32:37 -
> > @@ -808,7 +808,7 @@
> > 
> > /* A CSS stylesheet allows minimal customization by the user */
> > style = "body { background-color: white; color: black; font-family: "
> > -   "'Comic Sans MS', 'Chalkboard SE', 'Comic Neue', sans-serif; }\n"
> > +   "sans-serif; }\n"
> > "hr { border: 0; border-bottom: 1px dashed; }\n";
> > 
> > /* Generate simple HTML error document */
> > 
> > 
> 
> I don't like the default much either, but I don't think replacing one
> personal hard(ish)coded preference with another is the answer.
> 

Re: [PATCH] No comic sans in httpd status pages

[Theo de Raadt]

> I like the idea of just being able to specify a page to use for HTTP
> error codes.  If nobody beats me to it, I plan on taking a crack at
> implementing that feature, for my own use if nothing else.
> 
> In the mean time, I've done something similar to this patch, but I
> used monospace as the font. I also removed the "style" variable, used
> for the CSS snippet, since I don't think it adds anything to a
> bare-bones "404" page. 

I find this discussion pretty uninteresting.

I wish more people would find real bugs to fix.

Re: [PATCH] No comic sans in httpd status pages

[Stuart Henderson]

On 2016/02/19 21:51, Peter Krantz wrote:
> 
> > 19 feb. 2016 kl. 17:49 skrev Luis Coronado :
> > 
> > I believe this was intentional from the beginning: 
> > http://www.openbsd.org/papers/bsdcan14-libressl/mgp00025.html
> 
> Yeah, I figured. Nobody uses Comic Sans unintentionally :-)
> 
> Smart quotes and hurry killed the previous patch. This one works better as 
> ammunition in dialogue with  sysadmins. 

Probably too late for 5.9 but wouldn't it be better to use a separate
file for this like bgplg does? Then people can paint their own bikeshed
without recompiling or imposing their aesthetics on others.

> 
> ? no_comic_sans_in_404.patch
> Index: server_http.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
> retrieving revision 1.105
> diff -u -r1.105 server_http.c
> --- server_http.c 11 Feb 2016 19:30:04 -  1.105
> +++ server_http.c 19 Feb 2016 20:32:37 -
> @@ -808,7 +808,7 @@
> 
>   /* A CSS stylesheet allows minimal customization by the user */
>   style = "body { background-color: white; color: black; font-family: "
> - "'Comic Sans MS', 'Chalkboard SE', 'Comic Neue', sans-serif; }\n"
> + "sans-serif; }\n"
>   "hr { border: 0; border-bottom: 1px dashed; }\n";
> 
>   /* Generate simple HTML error document */
> 
> 

I don't like the default much either, but I don't think replacing one
personal hard(ish)coded preference with another is the answer.

Re: Enabling audio Realtek ALC1150

[Alexandre H]

Hello

The diffs were not completely commited...
I have sent some diffs for three elements :
pcidevs, azalia.c and azalia_codec.c

But the diff for azalia.c has not been commited.
Without this diff, the PCI config. is not done and so the chip doesn't
work, this diff is mandatory.
So I resend all the diffs followed by a dmesg from 5.8-release.



With the following diffs sndiod and aucat work.

# diff -u pcidevs.ori pcidevs
--- pcidevs.ori Fri Jun  5 07:24:08 2015
+++ pcidevs Mon Jun 29 23:20:30 2015
@@ -4564,6 +4564,7 @@
  product INTEL C610_PCIE_6  0x8d1a  C610 PCIE
  product INTEL C610_PCIE_7  0x8d1c  C610 PCIE
  product INTEL C610_PCIE_8  0x8d1e  C610 PCIE
+product INTEL C610_HDA 0x8d20  C610 HD Audio
  product INTEL C610_SMB 0x8d22  C610 SMBus
  product INTEL C610_EHCI_1  0x8d26  C610 USB
  product INTEL C610_EHCI_2  0x8d2d  C610 USB
# diff -u azalia.c.ori azalia.c
--- azalia.c.oriMon May 11 08:46:21 2015
+++ azalia.cMon Jun 29 23:20:09 2015
@@ -463,6 +463,7 @@
 case PCI_PRODUCT_INTEL_8SERIES_LP_HDA:
 case PCI_PRODUCT_INTEL_9SERIES_HDA:
 case PCI_PRODUCT_INTEL_9SERIES_LP_HDA:
+   case PCI_PRODUCT_INTEL_C610_HDA:
 case PCI_PRODUCT_INTEL_BAYTRAIL_HDA:
 reg = azalia_pci_read(az->pc, az->tag,
 INTEL_PCIE_NOSNOOP_REG);
# diff -u azalia_codec.c.ori azalia_codec.c
--- azalia_codec.c.ori  Sat Apr 25 13:37:24 2015
+++ azalia_codec.c  Mon Jun 29 23:20:09 2015
@@ -170,6 +170,9 @@
 this->name = "Realtek ALC888";
 this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D;
 break;
+   case 0x10ec0900:
+   this->name = "Realtek ALC1150";
+   break;
 case 0x11060398:
 case 0x11061398:
 case 0x11062398:



OpenBSD 5.8 (CUSTOM.MP-0) #1: Fri Feb 19 13:38:39 CET 2016
r...@makix.my.domain:/usr/src/sys/arch/amd64/compile/CUSTOM.MP-0
real mem = 34265309184 (32677MB)
avail mem = 33222918144 (31683MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x5ce4d000 (32 entries)
bios0: vendor American Megatrends Inc. version "P2.00" date 06/01/2015
bios0: ASRock X99 Extreme4
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG UEFI BDAT HPET MSCT PMCT 
SLIT SRAT WDDT SSDT AAFT DMAR ASF!
acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) IP2P(S4) XHCI(S4) 
EHC1(S4) EHC2(S4) RP01(S4) RP02(S4) RP03(S4) RP04(S4) RP05(S4) RP06(S4) 
RP07(S4) RP08(S4) BR1A(S4) [...]

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz, 3299.44 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT

cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz, 3299.05 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT

cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz, 3299.05 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT

cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz, 3299.05 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT

cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0

x86: bump boot(8) version

[Christian Weisgerber]

We should have bumped the bootstrap version after the mdrandom()
changes, shouldn't we?

Index: arch/amd64/stand/boot/conf.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/boot/conf.c,v
retrieving revision 1.33
diff -u -p -r1.33 conf.c
--- arch/amd64/stand/boot/conf.c18 Sep 2015 13:30:56 -  1.33
+++ arch/amd64/stand/boot/conf.c19 Feb 2016 20:52:55 -
@@ -41,7 +41,7 @@
 #include 
 #include 
 
-const char version[] = "3.29";
+const char version[] = "3.30";
 intdebug = 1;
 
 
Index: arch/amd64/stand/cdboot/conf.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/cdboot/conf.c,v
retrieving revision 1.28
diff -u -p -r1.28 conf.c
--- arch/amd64/stand/cdboot/conf.c  18 Sep 2015 13:30:56 -  1.28
+++ arch/amd64/stand/cdboot/conf.c  19 Feb 2016 20:53:02 -
@@ -42,7 +42,7 @@
 #include 
 #include 
 
-const char version[] = "3.24";
+const char version[] = "3.25";
 intdebug = 1;
 
 
Index: arch/amd64/stand/efiboot/conf.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/conf.c,v
retrieving revision 1.2
diff -u -p -r1.2 conf.c
--- arch/amd64/stand/efiboot/conf.c 2 Sep 2015 04:09:24 -   1.2
+++ arch/amd64/stand/efiboot/conf.c 19 Feb 2016 20:53:07 -
@@ -37,7 +37,7 @@
 #include "efiboot.h"
 #include "efidev.h"
 
-const char version[] = "3.29";
+const char version[] = "3.30";
 
 #ifdef EFI_DEBUG
 intdebug = 0;
Index: arch/amd64/stand/pxeboot/conf.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/pxeboot/conf.c,v
retrieving revision 1.32
diff -u -p -r1.32 conf.c
--- arch/amd64/stand/pxeboot/conf.c 18 Sep 2015 13:30:56 -  1.32
+++ arch/amd64/stand/pxeboot/conf.c 19 Feb 2016 20:53:12 -
@@ -44,7 +44,7 @@
 #include "pxeboot.h"
 #include "pxe_net.h"
 
-const char version[] = "3.24";
+const char version[] = "3.25";
 intdebug = 0;
 
 void (*sa_cleanup)(void) = pxe_shutdown;
Index: arch/i386/stand/boot/conf.c
===
RCS file: /cvs/src/sys/arch/i386/stand/boot/conf.c,v
retrieving revision 1.57
diff -u -p -r1.57 conf.c
--- arch/i386/stand/boot/conf.c 18 Sep 2015 13:30:56 -  1.57
+++ arch/i386/stand/boot/conf.c 19 Feb 2016 20:56:14 -
@@ -42,7 +42,7 @@
 #include 
 #include "debug.h"
 
-const char version[] = "3.27";
+const char version[] = "3.28";
 intdebug = 1;
 
 
Index: arch/i386/stand/cdboot/conf.c
===
RCS file: /cvs/src/sys/arch/i386/stand/cdboot/conf.c,v
retrieving revision 1.26
diff -u -p -r1.26 conf.c
--- arch/i386/stand/cdboot/conf.c   18 Sep 2015 13:30:56 -  1.26
+++ arch/i386/stand/cdboot/conf.c   19 Feb 2016 20:56:19 -
@@ -43,7 +43,7 @@
 #include 
 #include "debug.h"
 
-const char version[] = "3.24";
+const char version[] = "3.25";
 intdebug = 1;
 
 void (*sa_cleanup)(void) = NULL;
Index: arch/i386/stand/pxeboot/conf.c
===
RCS file: /cvs/src/sys/arch/i386/stand/pxeboot/conf.c,v
retrieving revision 1.31
diff -u -p -r1.31 conf.c
--- arch/i386/stand/pxeboot/conf.c  18 Sep 2015 13:30:56 -  1.31
+++ arch/i386/stand/pxeboot/conf.c  19 Feb 2016 20:56:23 -
@@ -45,7 +45,7 @@
 #include "pxeboot.h"
 #include "pxe_net.h"
 
-const char version[] = "3.24";
+const char version[] = "3.25";
 intdebug = 1;
 
 void (*sa_cleanup)(void) = pxe_shutdown;
-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: [PATCH] No comic sans in httpd status pages

[Peter Krantz]

> 19 feb. 2016 kl. 17:49 skrev Luis Coronado :
> 
> I believe this was intentional from the beginning: 
> http://www.openbsd.org/papers/bsdcan14-libressl/mgp00025.html

Yeah, I figured. Nobody uses Comic Sans unintentionally :-)

Smart quotes and hurry killed the previous patch. This one works better as 
ammunition in dialogue with  sysadmins. 


? no_comic_sans_in_404.patch
Index: server_http.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
retrieving revision 1.105
diff -u -r1.105 server_http.c
--- server_http.c   11 Feb 2016 19:30:04 -  1.105
+++ server_http.c   19 Feb 2016 20:32:37 -
@@ -808,7 +808,7 @@

/* A CSS stylesheet allows minimal customization by the user */
style = "body { background-color: white; color: black; font-family: "
-   "'Comic Sans MS', 'Chalkboard SE', 'Comic Neue', sans-serif; }\n"
+   "sans-serif; }\n"
"hr { border: 0; border-bottom: 1px dashed; }\n";

/* Generate simple HTML error document */

Re: [PATCH] No comic sans in httpd status pages

[Landry Breuil]

On Fri, Feb 19, 2016 at 05:40:33PM +0100, Peter Krantz wrote:
> Hi!
> 
> For some reason the httpd status pages (e.g. 404) use the Comic Sans 
> typeface. This patch removes comic sans and sets the typeface to the default 
> sans-serif typeface of the client.
> 
> This lowers the number of people contacting website maintainers with typeface 
> complaints bordering on harassment.

Sigh, people have no sense of humor those days..

Landry


pgpPiPWr713j0.pgp
Description: PGP signature

Re: [PATCH] No comic sans in httpd status pages

[Luis Coronado]

I believe this was intentional from the beginning:
http://www.openbsd.org/papers/bsdcan14-libressl/mgp00025.html

-luis


On Fri, Feb 19, 2016 at 10:40 AM, Peter Krantz  wrote:

> Hi!
>
> For some reason the httpd status pages (e.g. 404) use the Comic Sans
> typeface. This patch removes comic sans and sets the typeface to the
> default sans-serif typeface of the client.
>
> This lowers the number of people contacting website maintainers with
> typeface complaints bordering on harassment.
>
> Cheers,
>
> Peter
>
>
> ? no_comic_sans_in_404.patch
> Index: server_http.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
> retrieving revision 1.105
> diff -r1.105 server_http.c
> 811c811
> <   "'Comic Sans MS', 'Chalkboard SE', 'Comic Neue', sans-serif;
> }\n"
> ---
> >   "sans-serif; }\n”
>
>
>

[PATCH] No comic sans in httpd status pages

[Peter Krantz]

Hi!

For some reason the httpd status pages (e.g. 404) use the Comic Sans typeface. 
This patch removes comic sans and sets the typeface to the default sans-serif 
typeface of the client.

This lowers the number of people contacting website maintainers with typeface 
complaints bordering on harassment.

Cheers,

Peter


? no_comic_sans_in_404.patch
Index: server_http.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
retrieving revision 1.105
diff -r1.105 server_http.c
811c811
<   "'Comic Sans MS', 'Chalkboard SE', 'Comic Neue', sans-serif; }\n"
---
>   "sans-serif; }\n”




signature.asc
Description: Message signed with OpenPGP using GPGMail

[PATCH] install efi bootloader into an additional directory

[Remi Locherer]

Nobody else using OpenBSD on in an UEFI multiboot setup?

On Thu, Jan 28, 2016 at 09:04:40AM +0100, Remi Locherer wrote:
> Hi
> 
> Since we have efiboot creating a multiboot environment on amd64/i386
> became simpler. One obstacle is that (all?) OSs write their bootloader
> to the default loction efi/boot/ on the EFI Sys partition.
> 
> Some OSs also create an efi/XXX directory where they put most of their
> stuff (centos, ubuntu, win 10, ...).
> 
> With the below patch OpenBSDs installboot places the efiboot binaries in
> the addidional location efi/openbsd. A user that configures a multiboot
> environment can then register the OS specific loader with the EFI firmware.
> 
> With that OpenBSD will just boot after an upgrade without manual intervention
> and the installation of an addition OS will not break OpenBSD boot process.
> 
> Remi
> 
> 
> 
> Index: i386_installboot.c
> ===
> RCS file: /cvs/src/usr.sbin/installboot/i386_installboot.c,v
> retrieving revision 1.26
> diff -u -p -r1.26 i386_installboot.c
> --- i386_installboot.c28 Dec 2015 23:00:29 -  1.26
> +++ i386_installboot.c28 Jan 2016 07:48:31 -
> @@ -223,9 +223,10 @@ write_efisystem(struct disklabel *dl, ch
>   static char *newfsfmt ="/sbin/newfs_msdos %s >/dev/null";
>   struct msdosfs_args args;
>   char cmd[60];
> - char dst[50];   /* /tmp/installboot.XX/efi/BOOT/BOOTIA32.EFI */
> + char dst[50];  /* /tmp/installboot.XX/efi/BOOT/BOOTIA32.EFI
> */
> + char dst2[53]; /* /tmp/installboot.XX/efi/OPENBSD/BOOTIA32.EFI 
> */
>   char *src;
> - size_t mntlen, pathlen, srclen;
> + size_t mntlen, pathlen, pathlen2, srclen;
>   int rslt;
>  
>   src = NULL;
> @@ -286,7 +287,7 @@ write_efisystem(struct disklabel *dl, ch
>   }
>   }
>  
> - /* Create "/efi/BOOT" directory in .. */
> + /* Create "/efi/BOOT" and "/efi/OPENBSD" directory in .. */
>   if (strlcat(dst, "/efi", sizeof(dst)) >= sizeof(dst)) {
>   rslt = -1;
>   warn("unable to build /efi directory");
> @@ -297,6 +298,7 @@ write_efisystem(struct disklabel *dl, ch
>   warn("mkdir('%s') failed", dst);
>   goto umount;
>   }
> + memcpy(dst2, dst, sizeof(dst));
>   if (strlcat(dst, "/BOOT", sizeof(dst)) >= sizeof(dst)) {
>   rslt = -1;
>   warn("unable to build /BOOT directory");
> @@ -307,18 +309,35 @@ write_efisystem(struct disklabel *dl, ch
>   warn("mkdir('%s') failed", dst);
>   goto umount;
>   }
> + if (strlcat(dst2, "/OPENBSD", sizeof(dst2)) >= sizeof(dst2)) {
> + rslt = -1;
> + warn("unable to build /OPENBSD directory");
> + goto umount;
> + }
> + rslt = mkdir(dst2, 0);
> + if (rslt == -1 && errno != EEXIST) {
> + warn("mkdir('%s') failed", dst2);
> + goto umount;
> + }
>  
>   /*
> -  * Copy BOOTIA32.EFI and BOOTX64.EFI to /efi/BOOT/.
> +  * Copy BOOTIA32.EFI and BOOTX64.EFI to /efi/BOOT/ and /efi/OPENBSD.
>*
>* N.B.: BOOTIA32.EFI is longer than BOOTX64.EFI, so src can be reused!
>*/
>   pathlen = strlen(dst);
>   if (strlcat(dst, "/BOOTIA32.EFI", sizeof(dst)) >= sizeof(dst)) {
>   rslt = -1;
> - warn("unable to build /BOOTIA32.EFI path");
> + warn("unable to build /efi/BOOT/BOOTIA32.EFI path");
> + goto umount;
> + }
> + pathlen2 = strlen(dst2);
> + if (strlcat(dst2, "/BOOTIA32.EFI", sizeof(dst2)) >= sizeof(dst2)) {
> + rslt = -1;
> + warn("unable to build /efi/OPENBSD/BOOTIA32.EFI path");
>   goto umount;
>   }
> +
>   src = fileprefix(root, "/usr/mdec/BOOTIA32.EFI");
>   if (src == NULL) {
>   rslt = -1;
> @@ -326,19 +345,28 @@ write_efisystem(struct disklabel *dl, ch
>   }
>   srclen = strlen(src);
>   if (verbose)
> - fprintf(stderr, "%s %s to %s\n",
> - (nowrite ? "would copy" : "copying"), src, dst);
> + fprintf(stderr, "%s %s to %s and %s\n",
> + (nowrite ? "would copy" : "copying"), src, dst, dst2);
>   if (!nowrite) {
>   rslt = filecopy(src, dst);
>   if (rslt == -1)
>   goto umount;
> + rslt = filecopy(src, dst2);
> + if (rslt == -1)
> + goto umount;
>   }
>   src[srclen - strlen("/BOOTIA32.EFI")] = '\0';
>  
>   dst[pathlen] = '\0';
>   if (strlcat(dst, "/BOOTX64.EFI", sizeof(dst)) >= sizeof(dst)) {
>   rslt = -1;
> - warn("unable to build /BOOTX64.EFI dst path");
> + warn("unable to build /efi/BOOT/BOOTX64.EFI dst path");
> + goto umount;
> + }
> + dst2[pathlen2] = '\0';
> + if (strlcat(dst2, "/BOOTX64.EFI", 

Re: undefined behaviour in add_entropy_words()

[Martin Natano]

On Thu, Feb 18, 2016 at 09:11:18PM +0100, Stefan Kempf wrote:
>  
> I think we don't mix declarations and code.
> Would this be an option?
> 
> diff --git a/dev/rnd.c b/dev/rnd.c
> index 819ce0d..0f57b1b 100644
> --- a/dev/rnd.c
> +++ b/dev/rnd.c
> @@ -421,7 +421,7 @@ add_entropy_words(const u_int32_t *buf, u_int n)
>  
>   for (; n--; buf++) {
>   u_int32_t w = (*buf << entropy_input_rotate) |
> - (*buf >> (32 - entropy_input_rotate));
> + (*buf >> ((32 - entropy_input_rotate) & 31));
>   u_int i = entropy_add_ptr =
>   (entropy_add_ptr - 1) & POOLMASK;
>   /*

Yes, that should do.

>  
> > Index: dev/rnd.c
> > ===
> > RCS file: /cvs/src/sys/dev/rnd.c,v
> > retrieving revision 1.178
> > diff -u -p -u -r1.178 rnd.c
> > --- dev/rnd.c   8 Jan 2016 07:54:02 -   1.178
> > +++ dev/rnd.c   31 Jan 2016 10:11:17 -
> > @@ -420,8 +420,9 @@ add_entropy_words(const u_int32_t *buf, 
> > };
> >  
> > for (; n--; buf++) {
> > -   u_int32_t w = (*buf << entropy_input_rotate) |
> > -   (*buf >> (32 - entropy_input_rotate));
> > +   u_int32_t w = *buf << entropy_input_rotate;
> > +   if (entropy_input_rotate > 0)
> > +   w |= *buf >> (32 - entropy_input_rotate);
> > u_int i = entropy_add_ptr =
> > (entropy_add_ptr - 1) & POOLMASK;
> > /*
> > 
> > cheers,
> > natano
> >