Re: Wrong linkage to environ with -Wl,-nopie

[Josh Elsasser]

This problem still seems to be present. Anyone interested?

On Wed, Mar 07, 2018 at 01:40:37PM -0800, Josh Elsasser wrote:
> While testing lang/sbcl, I noticed that something appears to go wrong
> when linking a non-PIE executable which references environ. It looks
> like the executable ends up with it's own copy of environ, different
> from what libc uses.
> 
> The following program demonstrates this:
> 
> 
> 
> #include 
> #include 
> 
> extern char **environ;
> 
> int
> main()
> {
>   char *cmd[] = {"/usr/bin/printenv", "USER", NULL};
>   char *fakeenv[] = {"USER=nonexistent", NULL};
> 
>   environ = fakeenv;
> 
>   execv(cmd[0], cmd);
>   return 1;
> }
> 
> 
> 
> $ cc -o badenv-pie badenv.c  && ./badenv-pie  
>   
> nonexistent
> $ cc -fno-pie -Wl,-nopie -o badenv-nopie badenv.c && ./badenv-nopie 
> joshe
> 
> 
> It looks like what's happened is the linker has allocated a copy of
> environ in the BSS, separate from what libc is using:
> 
> $ objdump -t badenv-pie | grep environ
>   
>    O *UND*  0008 environ
> $ objdump -t badenv-nopie | grep environ
> 00601000  wO .bss   0008 environ
> 

Re: strtod() can change "nan" to -nan

[George Koehler]

On Mon, 16 Apr 2018 18:06:32 -0400
George Koehler  wrote:

>   In some platforms (like amd64, but not macppc), strtod(3)
>   flips the sign of not-a-number (nan).  It changes "nan" into
>   -nan and "-nan" into nan.

I had sent a patch for strtod() on amd64, but I forgot to fix
strtof() and strtold().  I now send a patch for all 3 functions on
amd64.  This patch also tries to fix alpha, arm, and i386, but I only
tested amd64.  I know that powerpc doesn't have the bug, and I guess
that other arches might not have the bug.

To check for the bug, compile this program "try.c":

#include 
#include 
int main(int argc, const char **argv) {
if (argc != 2) return 1;
printf("%g\n", strtof(argv[1], NULL));
printf("%g\n", strtod(argv[1], NULL));
printf("%Lg\n", strtold(argv[1], NULL));
return 0;
}

If the bug is fixed, then `./try nan` outputs `nan` 3 times, and
`./try -nan` outputs `-nan` 3 times.

To fetch the source code of OpenBSD, see
https://www.openbsd.org/faq/faq5.html#Bld

To apply the patch:
$ cd /usr/src/lib/libc
$ patch 

Re: NFS keeps crashing

[Theo de Raadt]

For a while it was amazing watching someone completely misunderstand
the Zeitgeist of the circumstances  this is open source, you get
all the pieces from people who largely care, but you also get all
the pieces so that you can DECIDE to care and FIX them when you find
problems and participate in a commonwealth of shared uplift.

But no.  You just bitch about it.  You do no self learning.  You are
simply demanding someone solve your problem because you are noisy.  Yes
self-learning is hard.  That's precisely what all of us did to be able
to maintain the software this far.  Now it is in your ballcourt.  If you
don't do so, that speaks much more to your character than to our
character.

Watching this isn't amazing anymore.  It is seriously sad.

I've come to the conclusion that if you were walking down the
sidewalk and found a poop in your way, you'd pull out your phone and
mail misc about it.  You don't know how to self-help.

Rupert - you got all the pieces, source code and all.  Without
warrantees, from volunteers.  Make them work, or use something else.  In
particular, I have to advice you on a bigger picture component: you need
to grow up.

Rupert Gallagher  wrote:

> The lack of information originates from "mountd -d". When it terminates 
> because of an error, it should log the name of the last function and its 
> parameters.
> 
> 
> 
> On Fri, Apr 27, 2018 at 02:04:35PM -0400, Rupert Gallagher wrote:
> 
> > Keeps crashing.
> >
> > ktrace attached.
> 
> No immediate clue pops up from the ktrace. I don't think I wil find
> the time to debug this futher the coming period.
> 
> -Otto
> 
> > ​​
> >
> > ‐‐‐ Original Message ‐‐‐
> >
> > On 26 April 2018 12:58 PM, Rupert Gallagher  wrote:
> >
> > > The following patch from Microsoft seems to restore functionality. Will 
> > > see in the following hours. The denial of service remains as a problem on 
> > > mountd. Will get a spare pc asap and check ktrace.
> > >
> > > https://support.microsoft.com/en-us/help/4088776/windows-10-update-kb4088776

Re: NFS keeps crashing

[Rupert Gallagher]

The lack of information originates from "mountd -d". When it terminates because 
of an error, it should log the name of the last function and its parameters.



On Fri, Apr 27, 2018 at 02:04:35PM -0400, Rupert Gallagher wrote:

> Keeps crashing.
>
> ktrace attached.

No immediate clue pops up from the ktrace. I don't think I wil find
the time to debug this futher the coming period.

-Otto

> ​​
>
> ‐‐‐ Original Message ‐‐‐
>
> On 26 April 2018 12:58 PM, Rupert Gallagher  wrote:
>
> > The following patch from Microsoft seems to restore functionality. Will see 
> > in the following hours. The denial of service remains as a problem on 
> > mountd. Will get a spare pc asap and check ktrace.
> >
> > https://support.microsoft.com/en-us/help/4088776/windows-10-update-kb4088776

Bugs on Toshiba Satellite L75 Notebook

[Elias M. Mariani]

Hi,
I found 2 bugs using -current on my notebook, both are minor bugs but
they exist, I dont have a problem myself with them but I think is
better to report them:

1-
Clean -current install.
Executed startx.
Screen off :(
After checking for errors in the console and in the logs I increased
the contrast and the screen came up (the contrast was so low on the
display that it seemed off).
So every time I start x have to increase the contrast from 0.

2-
Same case: clean -current install.
Pressing the power button or executing "shutdown -hp now" does most of
the process OK, until after the "Syncing Disks", after that the
machine panics, I dont know how to grab the information to debug with
ddb, if you can point me in the right direction I can try to pass the
error.
Again, no big problem, the disks are off so I can power-off the
Notebook by pushing the power button, just no auto-power-off.

Thanks for the great work.
Elias.

Environment:
System  : OpenBSD 6.3
Details : OpenBSD 6.3-current (GENERIC.MP) #13: Thu Apr 26
07:51:20 MDT 2018
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64

dmesg:
OpenBSD 6.3-current (GENERIC.MP) #13: Thu Apr 26 07:51:20 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 12780630016 (12188MB)
avail mem = 12385378304 (11811MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6e50 (26 entries)
bios0: vendor Insyde Corp. version "1.40" date 11/03/2014
bios0: TOSHIBA Satellite L75-B
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI FPDT MSDM ASF! HPET APIC MCFG SLIC WDAT
SSDT BOOT ASPT DBGP SSDT SSDT SSDT SSDT DMAR
acpi0: wakeup devices P0P1(S4) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(S3)
PXSX(S4) RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4)
PXSX(S4) PEG0(S4) PEGP(S4) PEG1(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz, 2594.37 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: cannot disable silicon debug
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, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz, 2594.00 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: cannot disable silicon debug
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz, 2594.01 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: cannot disable silicon debug
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz, 2594.00 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: cannot disable silicon debug
cpu3: smt 1, core 1, package 0
cpu4 at mainbus0: apid 4 (application processor)
cpu4: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz, 2594.01 MHz
cpu4: 

Re: Console resolution restricted to 848x400 on inteldrm

[Mark Kettenis]

> From: Thomas Sullivan 
> Date: Sat, 28 Apr 2018 04:03:27 +1000
> 
> I've tried reinstalling `amd64` and booting `bsd.sp` but I'm seeing the
> same thing.
> 
> Manually resetting `force` to false inside `intel_tv_detect` causes it to
> return the current connector status (presumably
> `connector_status_disconnected` but I haven't checked explicitly) and the
> console now fills the panel.
> 
> Looking into this a bit more, it seems like the return from
> `intel_tv_detect_type` is initially `DRM_MODE_CONNECTOR_SVIDEO` but on
> subsequent detections is `-1`, which causes `intel_tv_detect` to return
> `connector_status_connected` and `connector_status_disconnected`
> respectively:
> 
> ```
> $ grep '^\[drm:pid\d\+:intel_tv_detect' dmesg.1524564020
> [drm:pid0:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=1
> [drm:pid0:intel_tv_detect_type] TV detected: c00c7, cfaa
> [drm:pid0:intel_tv_detect_type] Detected S-Video TV connection
> [drm:pid85561:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=1
> [drm:pid85561:intel_tv_detect_type] TV detected: 500c00c7, 7faa
> [drm:pid85561:intel_tv_detect_type] Unrecognised TV connection
> [drm:pid85561:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=0
> [drm:pid85561:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=1
> [drm:pid85561:intel_tv_detect_type] TV detected: 500c00c7, 7faa
> [drm:pid85561:intel_tv_detect_type] Unrecognised TV connection
> [drm:pid85561:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=0
> [drm:pid85561:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=0
> [drm:pid85561:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=0
> ```
> 
> Based on the dmesg, the incorrect detection seems to occur during the
> initial driver init, whereas subsequent during the hotplug:
> 
> ```
> $ grep -B1
> '^\[drm:pid\d\+:drm_helper_probe_single_connector_modes_merge_bits\]
> \[CONNECTOR:\d\+:LVDS-\]$' dmesg.1524564020
> [drm:pid0:intel_fbdev_init_bios] no active fbs found, not using BIOS config
> [drm:pid0:drm_helper_probe_single_connector_modes_merge_bits]
> [CONNECTOR:25:LVDS-]
> --
> [drm:pid85561:drm_fb_helper_hotplug_event]
> [drm:pid85561:drm_helper_probe_single_connector_modes_merge_bits]
> [CONNECTOR:25:LVDS-]
> --
> [drm:pid85561:drm_fb_helper_hotplug_event]
> [drm:pid85561:drm_helper_probe_single_connector_modes_merge_bits]
> [CONNECTOR:25:LVDS-]
> ```
> 
> Part of me feels that if `intel_tv_detect` returns
> `connector_status_disconnected` on later calls, then it would make sense to
> redo the logic relating to connector setup etc from
> `drm_fb_helper_initial_config` in `drm_fb_helper_hotplug_event`, but I'm
> not sure how far that deviates from what's expected, nor how much this eats
> into existing kernel structures.

We don't really want to deviate too much from the "upstrean" Linux
code here.  We do backport fixes from more recent versions of this
code, but fixes we add independently from Linux are likely to get lost
whenever we update to a newer codebase.

Re: NFS keeps crashing

[Otto Moerbeek]

On Fri, Apr 27, 2018 at 02:04:35PM -0400, Rupert Gallagher wrote:

> Keeps crashing. 
> 
> ktrace attached.

No immediate clue pops up from the ktrace. I don't think I wil find
the time to debug this futher the coming period.

-Otto

> ​​
> 
> ‐‐‐ Original Message ‐‐‐
> 
> On 26 April 2018 12:58 PM, Rupert Gallagher  wrote:
> 
> > The following patch from Microsoft seems to restore functionality. Will see 
> > in the following hours. The denial of service remains as a problem on 
> > mountd. Will get a spare pc asap and check ktrace. 
> > 
> > https://support.microsoft.com/en-us/help/4088776/windows-10-update-kb4088776

Re: Console resolution restricted to 848x400 on inteldrm

[Thomas Sullivan]

I've tried reinstalling `amd64` and booting `bsd.sp` but I'm seeing the
same thing.

Manually resetting `force` to false inside `intel_tv_detect` causes it to
return the current connector status (presumably
`connector_status_disconnected` but I haven't checked explicitly) and the
console now fills the panel.

Looking into this a bit more, it seems like the return from
`intel_tv_detect_type` is initially `DRM_MODE_CONNECTOR_SVIDEO` but on
subsequent detections is `-1`, which causes `intel_tv_detect` to return
`connector_status_connected` and `connector_status_disconnected`
respectively:

```
$ grep '^\[drm:pid\d\+:intel_tv_detect' dmesg.1524564020
[drm:pid0:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=1
[drm:pid0:intel_tv_detect_type] TV detected: c00c7, cfaa
[drm:pid0:intel_tv_detect_type] Detected S-Video TV connection
[drm:pid85561:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=1
[drm:pid85561:intel_tv_detect_type] TV detected: 500c00c7, 7faa
[drm:pid85561:intel_tv_detect_type] Unrecognised TV connection
[drm:pid85561:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=0
[drm:pid85561:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=1
[drm:pid85561:intel_tv_detect_type] TV detected: 500c00c7, 7faa
[drm:pid85561:intel_tv_detect_type] Unrecognised TV connection
[drm:pid85561:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=0
[drm:pid85561:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=0
[drm:pid85561:intel_tv_detect] [CONNECTOR:33:SVIDEO-] force=0
```

Based on the dmesg, the incorrect detection seems to occur during the
initial driver init, whereas subsequent during the hotplug:

```
$ grep -B1
'^\[drm:pid\d\+:drm_helper_probe_single_connector_modes_merge_bits\]
\[CONNECTOR:\d\+:LVDS-\]$' dmesg.1524564020
[drm:pid0:intel_fbdev_init_bios] no active fbs found, not using BIOS config
[drm:pid0:drm_helper_probe_single_connector_modes_merge_bits]
[CONNECTOR:25:LVDS-]
--
[drm:pid85561:drm_fb_helper_hotplug_event]
[drm:pid85561:drm_helper_probe_single_connector_modes_merge_bits]
[CONNECTOR:25:LVDS-]
--
[drm:pid85561:drm_fb_helper_hotplug_event]
[drm:pid85561:drm_helper_probe_single_connector_modes_merge_bits]
[CONNECTOR:25:LVDS-]
```

Part of me feels that if `intel_tv_detect` returns
`connector_status_disconnected` on later calls, then it would make sense to
redo the logic relating to connector setup etc from
`drm_fb_helper_initial_config` in `drm_fb_helper_hotplug_event`, but I'm
not sure how far that deviates from what's expected, nor how much this eats
into existing kernel structures.



Regards,

Tom Sullivan

Head Developer
*Most Significant Bit Software*

*e:*  t...@msbit.com.au
*p:*  +61 407 890 821 <+61407890821>

On Wed, Apr 25, 2018 at 12:46 AM, Thomas Sullivan  wrote:

>
>
> On Tue, 24 Apr 2018 at 11:37 pm, Thomas Sullivan  wrote:
>
>> Thanks Mark,
>>
>> That was my thought too, but it’s not hooked up to anything except power
>> and ethernet.
>>
>> On Tue, 24 Apr 2018 at 11:24 pm, Mark Kettenis 
>> wrote:
>>
>>> > From: Thomas Sullivan 
>>> >
>>> > HI all,
>>> >
>>> > I've just installed 6.3 on my Early 2008 MacBook, with `inteldrm`
>>> graphics
>>> > and the console resolution seems misconfigured such that the screen
>>> > resolution is the full panel resolution at 1280x800 but the console
>>> itself
>>> > much smaller, and restricted to the top left corner. Since then I've
>>> > upgraded to the latest snapshot (22-Apr-2018) to no avail.
>>> >
>>> > `wsconsctl` shows:
>>> >
>>> > ```
>>> > # wsconsctl display
>>> > display.type=inteldrm
>>> > display.width=848
>>> > display.height=480
>>> > display.depth=32
>>> > display.emulations=vt100
>>> > display.screentypes=std
>>> > display.focus=0
>>> > display.brightness=97.97%
>>> > display.screen_on=250
>>> > display.screen_off=0
>>> > display.vblank=off
>>> > display.kbdact=on
>>> > display.msact=on
>>> > display.outact=on
>>> > ```
>>> >
>>> > Attached is `dmesg` from a kernel built with:
>>> >
>>> > ```
>>> > option  DRMDEBUG
>>> > option  MSGBUFSIZE=65536
>>> > ```
>>> >
>>> > and a picture of the console (spewing data to fill the available
>>> space).
>>> >
>>> > Regards,
>>> >
>>> > Tom Sullivan
>>>
>>> Hi Tom,
>>>
>>> Thanks for providing the DRMDEBUG dmesg.  For some reason the
>>> inteldrm(4) code detects a connection on the S-Video connector.  Since
>>> the default is to mirror the console framebuffer on all connected
>>> outputs, the framebuffer is configured as 848x480 such that the full
>>> contents are visible on both outputs.
>>>
>>> It seems this model does indeed have a S-Video output.  Do you have
>>> that hooked up to something?
>>>
>>> Cheers,
>>>
>>> Mark
>>>
>>> --
> Regards,
>
> Tom Sullivan
>
> Head Developer
> *Most Significant Bit Software*
>
> *e:*  t...@msbit.com.au
> *p:*  +61 407 890 821
>