Re: Performance issue on 7.5

[Matthieu Herrb]

On Sat, Jun 01, 2024 at 09:40:48PM +0200, Sacha wrote:
> Le 01/06/2024 à 14:04, Matthieu Herrb a écrit :
> > On Sat, Jun 01, 2024 at 11:57:35AM +0200, Sacha wrote:
> > > Dear list,
> > > 
> > > We have a performance issue impacting all our infrastructure behind our
> > > OpenBSD: two front BGP/CARP routers with 1Gb/s transit. It seams to occur
> > > since we have upgraded to 7.5, both of the servers are up to date.
> > Hi Sacha,
> > 
> > Can you check the traffic on the pfsync link ?
> > If it's abnormally high, it may be part of the problem and the patch
> > in https://marc.infœ?l=openbsd-tech=171605571513642=2
> > may help.
> > 
> Salut Matthieu,
> 
> glad to have new from you :)
> 
> No pfsync link: no pf on the front routers.

Salut,

If there's no pfsync link then I've no idea. But start looking at
systat(8) output for the sources of interrupts.

And if you want help from here, you should provide at least a dmesg
for these machines, so people have an idea of which network devices
you're using (and possible issues with the corresponding drivers...).

-- 
Matthieu Herrb

Re: Performance issue on 7.5

[Matthieu Herrb]

On Sat, Jun 01, 2024 at 11:57:35AM +0200, Sacha wrote:
> Dear list,
> 
> We have a performance issue impacting all our infrastructure behind our
> OpenBSD: two front BGP/CARP routers with 1Gb/s transit. It seams to occur
> since we have upgraded to 7.5, both of the servers are up to date.

Hi Sacha,

Can you check the traffic on the pfsync link ?
If it's abnormally high, it may be part of the problem and the patch
in https://marc.infœ?l=openbsd-tech=171605571513642=2
may help.

-- 
Matthieu Herrb

Re: WireGuard(?) issues

[Matthieu Herrb]

On Mon, May 20, 2024 at 11:53:26AM +0200, Martin Pieuchot wrote:
> On 19/05/24(Sun) 23:50, Vitaliy Makkoveev wrote:
> > 
> > 
> > > On 19 May 2024, at 22:05, Anthony J. Bentley  wrote:
> > > 
> > > Vitaliy Makkoveev writes:
> > >>> On 17 May 2024, at 12:06, Stuart Henderson  =
> > >> wrote:
> > >>> =20
> > >>> There are problems with wg(4) that people with some workloads have =
> > >> been
> > >>> seeing after upgrading past 7.3, though looking at this thread from =
> > >> when
> > >>> it last came up https://marc.info/?t=3D17094089271=3D1=3D2 I'm =
> > >> not
> > >>> sure if we'd be expecting to see trouble on non-MP=E2=80=A6
> > >>> =20
> > >> 
> > >> We do. The problem is not MP related.
> > >> 
> > >> Antony, does the diff [1] help?
> > >> 
> > >> 1. https://marc.info/?l=3Dopenbsd-bugs=3D170980835807159=3D2
> > > 
> > > Crashes continue to occur with the same frequency after patching.
> > > 
> > 
> > This could be vio(4) bug. Please try this [1] diff.
> > 
> > 1. https://marc.info/?l=openbsd-tech=171588941332420=2
> 
> The traces all point to a use-after-free in a mbuf that has been through
> the wg(4) machinery.  The fact that using a SP system makes the crash
> disappear points that this driver is not MP-safe and somehow there is a
> race which ends up corrupting memory associated to mbufs.

But only for some kind of workload / packets.

I've a machine that is running a service (HTTPS) behind a wireguard
connexion on OpenBSD-current. It has been running stable for several
months (I upgrade the machine almost every week).

OpenBSD 7.5-current (GENERIC.MP) #76: Fri May 17 10:28:20 MDT 2024
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2051219456 (1956MB)
avail mem = 1968062464 (1876MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7b923000 (51 entries)
bios0: vendor American Megatrends Inc. version "YB1007" date 08/17/2017
bios0: AZW Z83 II
efi0 at bios0: UEFI 2.4
efi0: American Megatrends rev 0x5000b
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI HPET SSDT SSDT 
SSDT SSDT TPM2 LPIT BCFG PRAM BGRT CSRT WDAT
acpi0: wakeup devices
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) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 1440.23 MHz, 06-4c-04, patch 
0411
cpu0: cpuid 1 
edx=bfebfbff
 
ecx=43d8e3bf
cpu0: cpuid 6 eax=7 ecx=9
cpu0: cpuid 7.0 ebx=2282 
edx=c000400
cpu0: cpuid a vers=3, gp=2, gpwidth=40, ff=3, ffwidth=40
cpu0: cpuid 8001 edx=28100800 ecx=101
cpu0: cpuid 8007 edx=100
cpu0: MELTDOWN
cpu0: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 79MHz
cpu0: mwait min=64, max=64, C-substates=0.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 1440.46 MHz, 06-4c-04, patch 
0411
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 1440.75 MHz, 06-4c-04, patch 
0411
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz, 1440.78 MHz, 06-4c-04, patch 
0411
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus -1 (RP02)
acpiprt3 at acpi0: bus -1 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
"INT33A4" at acpi0 not configured
iosf0 at acpi0 MBID: mbi
chvgpio0 at acpi0 GPO1 uid 2 addr 0xfed88000/0x8000 irq 48, 59 pins
chvgpio1 at acpi0 GPO3 uid 4 addr 0xfed98000/0x8000 irq 91, 55 pins
dwiic0 at acpi0 I2C7 addr 0x91526000/0x1000 irq 38, sem
iic0 at dwiic0
"INT33F4" at iic0 addr 0x34 not configured
chvgpio2 at acpi0 GPO0 uid 1 addr 0xfed8/0x8000 irq 49, 56 pins
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
com0 at acpi0 IURT addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
sdhc0 at acpi0 SDHA addr 0x9153a000/0x1000 irq 45
sdhc0: SDHC 3.00, 200 MHz base clock
sdmmc0 at sdhc0: 8-bit, sd high-speed, mmc high-speed, ddr52, dma
sdhc1 at acpi0 SDHB addr 0x91538000/0x1000 irq 46
chvgpio3 at acpi0 GPO2 uid 3 addr 0xfed9/0x8000 irq 50, 24 pins
sdhc1: SDHC 3.00, 200 MHz base clock
sdmmc1 at sdhc1: 4-bit, sd high-speed, mmc high-speed, ddr52, dma
sdhc2 at acpi0 SHC1 addr 0x91536000/0x1000 irq 47, gpio
sdhc2: SDHC 3.00, 200 MHz base clock
sdmmc2 at sdhc2: 4-bit, sd high-speed, mmc high-speed, ddr52, dma
"INTL9C60" at acpi0 not configured
"INTL9C60" at acpi0 not configured
"8086228A" at acpi0 not configured
"BCM2EA4" at acpi0 not configured

tcdpump -i pfsync0 broken

[Matthieu Herrb]

Hi,

On OpenBSD 7.5 and -current tcpdump on pfsync interfaces stopped
working. Morover running it with malloc_conf=S make it dump core.

How to repeat ?

Setup a pair of firewalls with carp(4) and pfsync(4).
Run tcpdump -n -i pfsync0  on one of the firewalls.

Expected result

In OpenBSD 7.3 one sees a dump of pfsync(4) packets transiting on the
interface.

Observed behaviour

On OpenBSD 7.4 and later:

pfctl -n -i pfsync0 only displays:

tcpdump: listening on pfsync0, link-type PFSYNC
20:29:20.753651 PFSYNCv69 len 1500
20:29:20.764775 PFSYNCv69 len 1428
20:29:20.772390 PFSYNCv69 len 1488
20:29:20.778919 PFSYNCv69 len 1428
20:29:20.786316 PFSYNCv69 len 1500

(the '69' is a wrong pfsync version, hence the rest of the bogus
packet is not dumped)

pfctl -s 1500 -X -n -i pfsync0 dumps core after a few packets. Note
how it reads much more data than a single packet...

GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd7.5".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./obj/tcpdump...
(gdb) r -s 1500 -X -n -i pfsync0
Starting program: /usr/obj/usr.sbin/tcpdump/tcpdump -s 1500 -X -n -i pfsync0
tcpdump: listening on pfsync0, link-type PFSYNC
21:52:09.889853 PFSYNCv69 len 128
  : 4510 0080 dd7b 4000 fff0     E{@.
  0010: 0a00 0101 0600 006c      ...l
  0020:     0415 0001 662f 961e  f/..
  0030: 0567 6a6e     6acb 63ed  .gjnj.c.
  0040: 6acb da6d   faf0  0988   j..m
  0050:          
  0060:  faf0   0001  0200   
  0070:   de0b f9cf   0500   
  0080: 699d 3266 fe94 0d00 8000  8000   i.2f
  0090: 1c00   2300   4510 0080  ..#.E...
  00a0: ab88 4000 fff0    0a00 0101  ..@.
  00b0: 0600 006c        ...l
  00c0:   0415 0001 662f 961e 0567 6a6e  f/...gjn
  00d0:     6acb 63ed 6acb da6d  j.c.j..m
  00e0:   faf0  0988     
  00f0:        faf0  
  0100:   0001  0200     
  0110: de0b f9cf   0500  699d 3266  i.2f
  0120: fb95 0d00 8000  8000  1c00   
  0130:  2300   4510 0080 c49e 4000  ..#.E.@.
  0140: fff0    0a00 0101 0600 006c  ...l
  0150:          
  0160: 0415 0001 662f 961e 0567 6a6e    f/...gjn
  0170:   6acb 63ed 6acb da6d    j.c.j..m
  0180: faf0  0988       
  0190:      faf0    
  01a0: 0001  0200    de0b f9cf  
  01b0:   0500  699d 3266 f896 0d00  i.2f
  01c0: 8000  8000  1c00   2300  ..#.
  01d0:   4510 0080 653f 4000 fff0   E...e?@.
  01e0:   0a00 0101 0600 006c    ...l
  01f0:       0415 0001  
  0200: 662f 961e 0567 6a6e      f/...gjn
  0210: 6acb 63ed 6acb da6d   faf0   j.c.j..m
  0220: 0988         
  0230:    faf0   0001   
  0240: 0200    de0b f9cf    
  0250: 0500  699d 3266 f697 0d00 8000   i.2f
  0260: 8000  1c00   2300    ..#.
  0270: 4510 0080 f6be 4000 fff0     E.@.
  0280: 0a00 0101 0600 006c      ...l
  0290:     0415 0001 662f 961e  f/..
  02a0: 0567 6a6e     6acb 63ed  .gjnj.c.
  02b0: 6acb da6d   faf0  0988   j..m
  02c0:          
  02d0:  faf0   0001  0200   
  02e0:   de0b f9cf   0500   
  02f0: 699d 3266 f298 0d00 8000  8000   i.2f
  

Re: X11 crashes when start Intellij IDEA

[Matthieu Herrb]

On Sat, Apr 27, 2024 at 07:20:15PM +0200, Kirill A. Korinsky wrote:
> On Sat, 27 Apr 2024 19:06:40 +0200,
> Matthieu Herrb  wrote:
> >
> > Does your Xorg.0.log say "X.Org X Server 1.21.1.12" or
> > "X.Org X Server 1.21.1.13" ?
> >
> >
> > There was a regression in Xorg 21.1.12 that may be the cause. It's
> > supposed to be fixed by 21.1.13 (it should be in recent snapshots).
> >
> 
> I do have crashes on 1.21.1.12 from snapshot which I've installed a few
> hours ago.

hmm yes oops I was sure I did commit 21.1.13 but apparently I
didn't. I'll fix that ASAP.

> 
> BTW I'd like to point that README need to be updated because NoTrapSignals
> where removed [1] from Xorg, and that changes were moved into xenocara as
> part of sync with xserver 21.1.0 [2].
> 
> Footnotes:
> [1]  
> https://gitlab.freedesktop.org/xorg/xserver/-/commit/c7414f4d07b69a4b2f0d0af06f032393cf5fe6aa
> 
> [2]  
> https://github.com/openbsd/xenocara/tree/e086cf5adf82811c219a3e76c4079278a4e75250
> 
> --
> wbr, Kirill
> 

-- 
Matthieu Herrb

Re: X11 crashes when start Intellij IDEA

[Matthieu Herrb]

On Sat, Apr 27, 2024 at 10:24:03AM -0400, Ian Darwin wrote:
> On 4/27/24 8:15 AM, Lucas Raab wrote:
> > Do you have a link to the project you're trying to run? I cloned the
> > scala3-example-project, installed scala/sbt, and was able to run it
> > without a crash. This was with:
> > OpenBSD 7.5-current (GENERIC.MP) #33: Sat Apr 27 01:25:59 MDT 2024
> > 
> I've also just started seeing this symptom after updating. The attached tiny
> project (not Scala) will crash X about one in five times that you open it,
> so it's not simply "open once and crash".
> 
> Happens on OpenBSD 7.5-current (GENERIC.MP) #31: Wed Apr 17 18:33:33 MDT
> 2024
> 
> Running xfce4 desktop - the OP didn't state what WM they are using.

Does your Xorg.0.log say "X.Org X Server 1.21.1.12" or
"X.Org X Server 1.21.1.13" ?


There was a regression in Xorg 21.1.12 that may be the cause. It's
supposed to be fixed by 21.1.13 (it should be in recent snapshots).

-- 
Matthieu Herrb

Re: X11 crashes when start Intellij IDEA

[Matthieu Herrb]

On Sat, Apr 27, 2024 at 02:42:23PM +0200, Kirill A. Korinsky wrote:
> On Sat, 27 Apr 2024 14:15:18 +0200,
> Lucas Raab  wrote:
> > 
> > Do you have a link to the project you're trying to run? I cloned the
> > scala3-example-project, installed scala/sbt, and was able to run it
> > without a crash. This was with:
> > OpenBSD 7.5-current (GENERIC.MP) #33: Sat Apr 27 01:25:59 MDT 2024
> 
> Unfortently it is private repo and I can't share it.
> 
> But this project contains a few extreamly large scala files (dozen of kb)
> with scalatests, and compuling thes files consume a lot of resources.
> 
> Anyway, this projects works fine if I build it by hand via sbt, and it
> defently had worked fine in IDEA at middle of March when I last time had
> touch it inside IDEA.
> 
> But the question is: what IDEA may trigger inside X11 that it crashes, and
> how can I future debug it?
> 
> I've tried to create folders for core dump as:
> 
> ~ $ ls -l /var/crash
> total 12
> drwxrwxrwx  2 root  wheel  512 Apr 27 14:05 X
> drwxrwxrwx  2 root  wheel  512 Apr 27 14:00 X11
> -rw-r--r--  1 root  wheel    5 Oct 10  2023 minfree
> ~ $ 
> 

The binary is Xorg. so create /var/crash/Xorg 

-- 
Matthieu Herrb

Re: xenodm doesn't login after enabling UTF-8 by setting LC_CTYPE

[Matthieu Herrb]

On Sat, Nov 25, 2023 at 10:02:38PM +0700, hahahahacker2...@airmail.cc wrote:
> > Synopsis:   cannot login after setting LC_CTYPE="en_US.UTF-8"
> > Category:   xenodm,utf8
> > Environment:
>   System  : OpenBSD 7.4
>   Details : OpenBSD 7.4-current (GENERIC.MP) #1461: Mon Nov 20 
> 19:55:51
> MST 2023
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> > Description:
> Adding the line export LC_CTYPE="en_US.UTF-8" then login, it just check the
> password, then fall back to the xenodm login screen.
> Can't find any log for the error, tried /var/log and logs at ~ but no
> result.

Hi,

If you only set LC_CTYPE in your .profile, xenodm itself doesn't see
it and its behaviour shouldn't change. It's your user session that is
now failing (but shouldn't...). There's probably a typo somewhere.

The error message is probably in ~/.xsession-errors or in
/var/log/xenodm.log

-- 
Matthieu Herrb

Re: X freeze with firefox/chromium on 7.4

[Matthieu Herrb]

On Sun, Nov 05, 2023 at 09:09:37PM +0100, Josh wrote:
> 
> chrome output before freeze:
> test# chrome --debug
> [67850:-1106581952:1104/174401.831825:ERROR:bus.co(406)] Failed to
> connect to the bust Failed to connect to socket
> /var/run/dbus/system_bus_socket: No such file or directory libGL
> error: MESA-LOADER: failed to retrieve device information
> libGL error: MESA-LOADER: failed to open andgpu: File not found
> (search paths /usr/Х116/lib/modules/dri, suffix_dri) libGL error:
> failed to load driver: andgpu

Even with the bad OCR, normally
/usr/X11R6/lib/modules/dri/amdgpu_dri.so should be present.

> libGL error: failed to open /dew/dri/card0: No such File on directory
> libGL error: failed to load drivert radeonsi

same both /dev/dri/card0 and
/usr/X11R6/lib/modules/dri/radeonsi_dri.so should exist

> libGL error: MESA-LOADER: failed to open swast: Cannot load specified
> object (search paths /us/W11RB/lib/modules/dri, suffix _dri) libGL
> error: failed to load driver: swrast

And so does  /usr/X11R6/lib/modules/dri/swrast_dri.so

I suspect something is busted on your installation, or you have
corrupted the unveil setup for chromium and/or firefox. check
/etc/chromium/unveil.*  and /etc/firefox/unveil.* files.

remove them and re-install the packages to make sure you have the
correct ones (or copy them back from /usr/local/share/examples/)
-- 
Matthieu Herrb

Re: Is it possible to use the amdgpu driver with my Amd R7-240 gpu ?

[Matthieu Herrb]

On Sat, Jun 24, 2023 at 07:35:30PM +0300, chris greek wrote:
> Is it possible to use the amdgpu driver with my Amd R7-240 gpu ?
> Do i have to modify and compile the kernel so it would use amdgpu instead
> of radeon ?

There is code to support your card (id 0x6631 if I figured it out
correctly) in the amdgpu driver indeed. So as Jonathan said in answer
to your previous mail you can tray to disable radrondrm from the boot
prompt:

  boot -c
  disable radeondrm*
  quit

Then  the amdgpu driver should attach to your card.

In addition you can force the download of the amdgpu firmware in
advance by running :

  fw_update amdgpu

If this works, see the config(8) manual page for details to save the
modified kernel.
-- 
Matthieu Herrb

Re: Minor bug in xcb_connect

[Matthieu Herrb]

On Tue, Jan 31, 2023 at 10:31:34PM +, cho...@jtan.com wrote:
> If the function implementing xcb_connect is called directly with a
> custom xcb_auth_info_t then checking that the screen in $DISPLAY
> is valid is skipped.
> 
> Matthew

Hi,

Thank you for this patch.  Can you also file a Merge Request to
upstream libxcb project at gitlab.freedesktop.org so that this can get
reviewed by libxcb developpers ?

https://gitlab.freedesktop.org/xorg/lib/libxcb/-/merge_requests

Regards, 
> 
> Index: xcb_util.c
> ===
> RCS file: /src/datum/openbsd/cvs/xenocara/dist/libxcb/src/xcb_util.c,v
> retrieving revision 1.13
> diff -u -p -r1.13 xcb_util.c
> --- xcb_util.c17 Jul 2022 08:31:10 -  1.13
> +++ xcb_util.c31 Jan 2023 22:20:24 -
> @@ -528,10 +528,8 @@ xcb_connection_t *xcb_connect_to_display
>  
>  if(auth) {
>  c = xcb_connect_to_fd(fd, auth);
> -goto out;
>  }
> -
> -if(_xcb_get_auth_info(fd, , display))
> +else if(_xcb_get_auth_info(fd, , display))
>  {
>  c = xcb_connect_to_fd(fd, );
>  free(ourauth.name);
> 

-- 
Matthieu Herrb

Re: Xorg crashes when cat'ing a binary file.

[Matthieu Herrb]

On Tue, Jan 31, 2023 at 06:25:30PM +, yaslam...@gmail.com wrote:
> >Synopsis:Xorg crashes when cat'ing a binary file.
> >Category:user
> >Environment:
>   System  : OpenBSD 7.2
>   Details : OpenBSD 7.2-current (GENERIC.MP) #1002: Sun Jan 29 
> 11:24:36 MST 2023
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   When cat'ing a binary file in, for example the Xfce Terminal, Xorg 
> crashes, and I am returned to the TTY where xenodm restarts and I can log 
> back in.
> >How-To-Repeat:
>   Log into a DE or WM with xenodm, open a terminal and do:
>   cat /dev/sd1a
>   You should see that Xorg crashes and you are returned to the
>   TTY.

Thanks for your report.

Could you also send us the /var/log/Xorg.0.log.old file (once xenodm  has
restarted) so that we can see the exact crash from the Xorg server ?


Thanks.
-- 
Matthieu Herrb

Re: cwm (and twm?) switch issue

[Matthieu Herrb]

On Sat, Dec 10, 2022 at 01:59:04PM +0100, Alessandro Ricci wrote:
> Start fvwm then switch to cwm, now execute the restart function.
> Then fvwm is spawned. Well done.
> That's because now argv[0] = fvwm.
> I don't think fvwm needs to change, cwm has to.

Hi,

I think it's a bug in fvwm. The patch below fixes it. (ie when
execvp(1) is called, the new argv[0] should be set to the new command,
not the one fvwm was stàrted with. Only lightly tested, other pairs of
eyes may be needed before this can be committed.

(Note: I've other unrelated stuff in my tree, so the line numbers are
a bit off, but the patch should apply nevertheless)

Index: app/fvwm/fvwm/fvwm.c
===
RCS file: /cvs/OpenBSD/xenocara/app/fvwm/fvwm/fvwm.c,v
retrieving revision 1.3
diff -u -p -u -r1.3 fvwm.c
--- app/fvwm/fvwm/fvwm.c15 Apr 2017 17:18:01 -  1.3
+++ app/fvwm/fvwm/fvwm.c10 Dec 2022 14:43:50 -
@@ -1486,9 +1482,10 @@ void Done(int restart, char *command)
   char *my_argv[10];
   int i,done,j;
 
-  i=0;
-  j=0;
+  i=1;
+  j=1;
   done = 0;
+  my_argv[0] = command;
   while((g_argv[j] != NULL)&&(i<8))
   {
 if(strcmp(g_argv[j],"-s")!=0)


-- 
Matthieu Herrb

Re: X segfault using startx

[Matthieu Herrb]

On Wed, Nov 09, 2022 at 06:22:13PM +0100, Walter Alejandro Iglesias wrote:
> Good evening,
> 
> Today after upgrading to the latest snapshot I coudn't run X using startx
> as I usually do.  I got this Xorg segfault:
> 
> (EE) Segmentation fault at address 0x1c
> (EE) 
> Fatal server error:
> (EE) Caught signal 11 (Segmentation fault). Server aborting
> 
> It happens only using startx.  I can still run X using xenodm
> (modesetting or intel) and als using startx as root, so it's surely some
> change in perms.
> 
Hi,

Sorry it's the fault of the upgrade to libpciaccess 0.17 that I
committed 2 days ago. I've just added a fix. It will be in a future
snapshot. 

-- 
Matthieu Herrb

Re: Xserver crash with cgoban

[Matthieu Herrb]

On Sun, Nov 06, 2022 at 07:07:06AM -0700, Todd C. Miller wrote:
> On Sun, 06 Nov 2022 10:44:10 +0000, Matthieu Herrb wrote:
> 
> > Thanks for the report. You're right that this was overlooked when I
> > wrote this code.
> >
> > I'd suggest the more complete (and paranoid) patch below:
> 
> I don't think you can set client->clientIds->cmdname to a constant
> string such as "" since it is freed later.  I think you want:
> 
> *cmdname = strdup("");

Yes you're right. In fact I was just looking at why my X server was
now abort()ing on exit while testing this :-)

New patch, that also fixes white space according to X.Org coding
rules.

Index: os/client.c
===
RCS file: /cvs/OpenBSD/xenocara/xserver/os/client.c,v
retrieving revision 1.5
diff -u -p -u -r1.5 client.c
--- os/client.c 11 Nov 2021 09:03:14 -  1.5
+++ os/client.c 6 Nov 2022 15:08:27 -
@@ -160,18 +160,26 @@ DetermineClientCmd(pid_t pid, const char
 if (n != 1)
 return;
 argv = kvm_getargv(kd, kp, 0);
-*cmdname = strdup(argv[0]);
-i = 1;
-while (argv[i] != NULL) {
-len += strlen(argv[i]) + 1;
-i++;
+if (cmdname) {
+if (argv == NULL || argv[0] == NULL) {
+*cmdname = strdup("");
+return;
+} else
+*cmdname = strdup(argv[0]);
 }
-*cmdargs = calloc(1, len);
-i = 1;
-while (argv[i] != NULL) {
-strlcat(*cmdargs, argv[i], len);
-strlcat(*cmdargs, " ", len);
-i++;
+if (cmdargs) {
+i = 1;
+while (argv[i] != NULL) {
+len += strlen(argv[i]) + 1;
+i++;
+}
+*cmdargs = calloc(1, len);
+i = 1;
+while (argv[i] != NULL) {
+strlcat(*(char **)cmdargs, argv[i], len);
+strlcat(*(char **)cmdargs, " ", len);
+i++;
+}
 }
 kvm_close(kd);
 }

-- 
Matthieu Herrb

Re: Xserver crash with cgoban

[Matthieu Herrb]

On Sat, Nov 05, 2022 at 08:55:46PM +0100, bau...@pestilenz.org wrote:

Hi,

Thanks for the report. You're right that this was overlooked when I
wrote this code.

I'd suggest the more complete (and paranoid) patch below:


Index: os/client.c
===
RCS file: /cvs/OpenBSD/xenocara/xserver/os/client.c,v
retrieving revision 1.5
diff -u -p -u -r1.5 client.c
--- os/client.c 11 Nov 2021 09:03:14 -  1.5
+++ os/client.c 6 Nov 2022 10:41:04 -
@@ -160,20 +160,28 @@ DetermineClientCmd(pid_t pid, const char
 if (n != 1)
 return;
 argv = kvm_getargv(kd, kp, 0);
-*cmdname = strdup(argv[0]);
-i = 1;
-while (argv[i] != NULL) {
-len += strlen(argv[i]) + 1;
-i++;
-}
-*cmdargs = calloc(1, len);
-i = 1;
-while (argv[i] != NULL) {
-strlcat(*cmdargs, argv[i], len);
-strlcat(*cmdargs, " ", len);
-i++;
-}
-kvm_close(kd);
+   if (cmdname) {
+   if (argv == NULL || argv[0] == NULL) {
+   *cmdname = ""; 
+   return;
+   } else 
+   *cmdname = strdup(argv[0]);
+   }
+   if (cmdargs) {
+   i = 1;
+   while (argv[i] != NULL) {
+   len += strlen(argv[i]) + 1;
+   i++;
+   }
+   *cmdargs = calloc(1, len);
+   i = 1;
+   while (argv[i] != NULL) {
+   strlcat(*(char **)cmdargs, argv[i], len);
+   strlcat(*(char **)cmdargs, " ", len);
+   i++;
+   }
+   }
+   kvm_close(kd);
 }
 #else   /* Linux using /proc/pid/cmdline */
 

> >Synopsis:programs can crash xenocara servers
> >Category:system
> >Environment:
>   System  : OpenBSD 7.1
>   Details : OpenBSD 7.1-current (GENERIC.MP) #20: Thu Jul  7 13:04:50 
> CEST 2022
>
> bau...@x220.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   X server(s) crash when certain programs run (e.g. cgoban-1.9.12p3)
> >How-To-Repeat:
> 
>   % doas pkg_add cgoban
>   % cgoban
> 
> 
>   If you want to keep your X Session:
> 
>   % Xephyr :1 &
>   % env DISPLAY=:1 cgoban
> 
> >Fix:
>   As the manpage kvm_getargv(3) explains, programs may put
>   anything in their argv. And cgoban seems to set *argv to
>   NULL. If xprop(1) is run on cgoban after patching xenocara with the
>   diff below, xprop shows 
>  WM_COMMAND(STRING) = {  }
> which supports my guess.
> 
>   
> Index: xserver/os/client.c
> ===
> RCS file: /cvs/xenocara/xserver/os/client.c,v
> retrieving revision 1.5
> diff -r1.5 client.c
> 163c163,170
> < *cmdname = strdup(argv[0]);
> ---
> > /* 
> >  * argvmay be NULL (error from kvm_getargv(3))
> >  * argv[0] may be NULL (cmd withheld by application)
> >  */
> > if (argv == NULL || argv[0] == NULL) 
> > *cmdname = strdup("");
> > else
> > *cmdname = strdup(argv[0]);
> 

-- 
Matthieu Herrb

Re: X crashes when moving cursor from keyboard (fvwm1, fvwm2 or cwm)

[Matthieu Herrb]

On Tue, Aug 30, 2022 at 05:05:09PM +0200, Walter Alejandro Iglesias wrote:
> Let me add that the machine is a Thinkpad T410 that I bought years ago
> *exclusively* to be able to run OpenBSD.  I used this machine with
> OpenBSD *snapshots* during several years as a desktop and web-mail
> server.  I mean, there's nothing "exotic" in my hardware
> configuration. :-)  And I can't either suspect hardware failure as a
> cause since I can also reproduce the bug in my HP dc7700CMT:

I'm sure it's a bug but whithout a stack trace it's hard to figure out
where the issue is.

I had a look on what cwm is doing in reaction to the keyboard
mapping. The little program is simulating this.

Can you build it and try to add  it at the start of your minimal
testing .xinitrc to see if it's enough to trigger the issue ?

to compile it :

cc -I/usr/X11R6/include -L/usr/X11R6/lib -o xmovepointer xmovepointer.c

--- cut xmovepointer.c ---
#include 
#include 
#include 
#include 

int
main(int argc, char *argv[])
{
Display *dpy;
int i;

dpy = XOpenDisplay(NULL);
if (dpy == NULL)
err(2, "Open Display");

printf("go\n");
for (i = 0; i < 1024; i++) {
XWarpPointer(dpy, None,  None,
0, 0, 0, 0, 0, 1);
XFlush(dpy);
// usleep(1000);
}
printf("done\n");
return 0;
}
--- cut ---


Another path is that you try to get an X server stack trace. Since
you're using startx it's easier than what is documented in
/usr/xenocara/README. Just create a /etc/X11/xorg.conf file containing

Section "ServerFlags"
Option  "NoTrapSignals" "true"
EndSection

and also rebuild the X server once more with :

doas make -f Makefile.bsd-wrapper build CFLAGS="-O0 -g"

Once it has crashed, you should have a Xorg.core file in your home
directory. To get a backtrace install egdb from packages (pkg_add gdb)
and run it

egdb /usr/xobj/xserver/hw/xfree86/Xorg Xorg.core

inside egdb run the 'bt' command.




-- 
Matthieu Herrb

Re: X crashes when moving cursor from keyboard (fvwm1, fvwm2 or cwm)

[Matthieu Herrb]

On Tue, Aug 30, 2022 at 03:35:56PM +0200, Walter Alejandro Iglesias wrote:
> On Aug 29 2022, Matthieu Herrb wrote:
> > On Sat, Aug 27, 2022 at 01:07:30PM +0200, Walter Alejandro Iglesias wrote:
> > > X crashes when moving cursor from keyboard bindings.  I can reproduce
> > > the bug with cwm, fvwm or fvwm2 (because this window managers have that
> > > option).  According to the logs the cause could be in wsmouse.
> > > 
> > > **IT'S NOT EASY TO REPRODUCE IT**.  Generally, but not necessarily is
> > > easier right after X started (when wsmouse is still being loaded), and
> > > stressing it, changing fast the direction.
> > >
> > 
> > Hi,
> > 
> > I also cannot reproduce it, however, I've some idea on what could be
> > happening.
> > 
> > Can you try the patch below ? It adds locking with the input thread of
> > the X server while adding new devices.
> 
> Matthieu, I'm very very sorry to say that I'm still able to reproduce
> it.  Again, it doesn't happen every time, I have to insist.
> 
> If you can think of anything else I can try let me know.
> 
> 
> I didn't mention the following warning that shows up every time I run
> startx, I ignore if it's related or even relevant:
> 
>   WARNING: Kernel has no file descriptor comparison support: No such a file 
> or directory
>

Could you share the contents of your .xinitrc file with us ? One thing
that may make the issue impossible to reproduce for others is that
somme applications (like ssh-add) grab the keyboard and so won't let
the mouse emulation code of the window manager inject motion events.


-- 
Matthieu Herrb

Re: X crashes when moving cursor from keyboard (fvwm1, fvwm2 or cwm)

[Matthieu Herrb]

On Sat, Aug 27, 2022 at 01:07:30PM +0200, Walter Alejandro Iglesias wrote:
> X crashes when moving cursor from keyboard bindings.  I can reproduce
> the bug with cwm, fvwm or fvwm2 (because this window managers have that
> option).  According to the logs the cause could be in wsmouse.
> 
> **IT'S NOT EASY TO REPRODUCE IT**.  Generally, but not necessarily is
> easier right after X started (when wsmouse is still being loaded), and
> stressing it, changing fast the direction.
>

Hi,

I also cannot reproduce it, however, I've some idea on what could be
happening.

Can you try the patch below ? It adds locking with the input thread of
the X server while adding new devices.

Index: config/wscons.c
===
RCS file: /cvs/OpenBSD/xenocara/xserver/config/wscons.c,v
retrieving revision 1.25
diff -u -r1.25 wscons.c
--- config/wscons.c 11 Jun 2019 14:51:34 -  1.25
+++ config/wscons.c 29 Aug 2022 18:53:31 -
@@ -113,9 +113,12 @@
 }
 close(fd);
 
+input_lock();
 input_options = input_option_new(input_options, "_source", 
"server/wscons");
-if (input_options == NULL)
+if (input_options == NULL) {
+input_unlock();
 return;
+}
 
 LogMessage(X_INFO, "config/wscons: checking input device %s\n",
WSCONS_KBD_DEVICE);
@@ -178,6 +181,7 @@
 }
  unwind:
 input_option_free_list(_options);
+input_unlock();
 }
 
 static void
@@ -194,9 +198,12 @@
 if (!config_info)
 return;
 
+input_lock();
 input_options = input_option_new(input_options, "_source", 
"server/wscons");
-if (input_options == NULL)
+if (input_options == NULL) {
+input_unlock();
 return;
+}
 
 input_options = input_option_new(input_options, "name", strdup(path));
 input_options = input_option_new(input_options, "driver", strdup(driver));
@@ -213,6 +220,7 @@
 }
  unwind:
     input_option_free_list(_options);
+input_unlock();
 }
 
 static void

-- 
Matthieu Herrb

Re: xlock don't take my password anymore

[Matthieu Herrb]

On Sun, Aug 14, 2022 at 01:05:49PM +0200, BESSOT Jean-Michel wrote:
> Hello
> 
> Xlock do not take my password since my last snapshot update (well there is
> time since the one before).
> 
> I use a bépo keyboard so kdb is set with fr dvorak
> 

Hi,

can you try the patch below (already tested by Denis, who provided a
hint on the issue) ?

(get the xenocara tree, apply in app/xlockmore using patch(1) and
rebuild xlockmore by running the following commands in
/usr/xenocara/app/xlockmore :

doas make -f Makefile.bsd-wrapper obj
doas make -f Makefile.bsd-wrapper build

Index: xlock/passwd.c
===
RCS file: /cvs/OpenBSD/xenocara/app/xlockmore/xlock/passwd.c,v
retrieving revision 1.3
diff -u -r1.3 passwd.c
--- xlock/passwd.c  26 Jun 2022 14:09:51 -  1.3
+++ xlock/passwd.c  22 Aug 2022 21:35:49 -
@@ -1279,16 +1279,19 @@
 #ifdef USE_PRIVSEP
char*pass;
char*style;
+   int  authok;
 
/* buffer can be in the form style:pass */
if ((pass = strchr(buffer, ':')) != NULL) {
*pass++ = '\0';
style = buffer;
-   } else {
-   pass = buffer;
-   style = NULL;
-   }
-   return priv_pw_check(user, pass, style);
+   authok = priv_pw_check(user, style, pass);
+   *--pass = ':';
+   } else 
+   authok = 0;
+   pass = buffer;
+   style = NULL;
+   return (authok || priv_pw_check(user, pass, style));
 #elif defined(BSD_AUTH)
char   *pass;
char   *style;


-- 
Matthieu Herrb

Re: xlock don't take my password anymore

[Matthieu Herrb]

On Sun, Aug 21, 2022 at 10:03:01PM +0200, Denis Fondras wrote:
> Le Sun, Aug 14, 2022 at 01:05:49PM +0200, BESSOT Jean-Michel a écrit :
> > Hello
> > 
> > Xlock do not take my password since my last snapshot update (well there is
> > time since the one before).
> > 
> > I use a bépo keyboard so kdb is set with fr dvorak
> > 
> > bye
> > 
> 
> Same here with US kb and an Intel NUC. I will try to debug this
> week...

What special configuration my you have ?
It's probably something that got overlooked when I added privsep +
unveil to xlock during r2k22, but I wonder what.

Unfortunatly since xlock is setgid, ktracing it is not trivial...

-- 
Matthieu Herrb

Re: fontconfig error

[Matthieu Herrb]

On Fri, Aug 05, 2022 at 06:46:34PM +0200, Walter Alejandro Iglesias wrote:
> 
> I compiled xterm with your patch.  With default settings xterm shows no
> error and the font selected is loaded correctly, and this is a detail I
> forgot to mention: before your patch, besides the error, the selected
> Xft font wasn't loaded.
> 
> But your patch solves the problem partially.  Let me explain my point,
> exactly because I don't like to modify system files and because at some
> point I got tired of freedesktop "innovations" and to find out what
> every Linux distribution or BSD system did in /etc/fonts, decades ago I
> decided to set FONTCONFIG_FILE variable to point to my ~/.fonts.conf
> (more late to ~/.config/fontsconfig/fonts.conf).  And I did something
> alike with all desktop related config files.  Fonts and icons I need are
> in my home dir too.  In that way just untaring my home directory I got
> my environment behaving in the way I wanted in any unix-like system.
> 
> Now, after applying your patch, setting FONTCONFIG_FILE and
> FONTCONFIG_PATH to my home config dir and file, xterm loads the xft font
> correctly but the error appears again.  I don't understand why since it
> seemed to me to see in the code (main.c) that home directory as well as
> the xdg direcories are also unveiled.
> 

The fontconfig library is really hostile to sandboxing attempts for
applications using it. If one looks at the code that was added to
xterm to cope with the various environment variables change the way it
looks for its configuration and locations where fonts can be found, it
already quite long and a similar bit of code needs to be added to
*any* application that links to fontconfig and wants to protect itself
using unveil.

In the long term it's really hard to maintain.

So at some point we need to give up on this pattern of making every
possible part of the system full configurable.

We may add support for FONTCONFIG_FILE and FONTCONFIG_PATH to xterm if
people really need it, but I don't think other applications that use
unveil and need to handle fontconfig (chromium and the mozillas come
to my mind) know about those variables.

-- 
Matthieu Herrb

Re: fontconfig error

[Matthieu Herrb]

On Thu, Aug 04, 2022 at 04:42:57PM +0200, Walter Alejandro Iglesias wrote:
> Run xterm with the default system Xresources, open the "VT Fonts" dialog
> (holding down Ctrl and pressing right mouse button) check TrueType
> Fonts.  At least to me, fontconfig writes the following error:
> 
>   $ xterm
>   Fontconfig error: Cannot load default config file: No such file:
>   (null)

Ok I understood this problem. It's caused by the fact that xterm is
accessing /etc/fonts after it's initialization, once unveil() has
entered into action.

One possible patch is to add /etc/fonts to the unveiled directories :

Index: app/xterm/main.c
===
RCS file: /cvs/OpenBSD/xenocara/app/xterm/main.c,v
retrieving revision 1.57
diff -u -p -u -r1.57 main.c
--- app/xterm/main.c22 May 2022 14:43:01 -  1.57
+++ app/xterm/main.c5 Aug 2022 13:31:15 -
@@ -2968,6 +2968,7 @@ main(int argc, char *argv[]ENVP_ARG)
}
 
unveil("/usr/X11R6", "r");
+   unveil("/etc/fonts", "r");
 unveil("/usr/local/share/fonts", "r");
unveil("/var/cache/fontconfig", "r");
unveil("/usr/local/share/icons", "r");

-- 
Matthieu Herrb

Re: fontconfig error

[Matthieu Herrb]

On Thu, Aug 04, 2022 at 04:42:57PM +0200, Walter Alejandro Iglesias wrote:
> Hello everyone,
> 
> Two days ago I installed OpenBSD (current) in my laptop after two years
> of not using it (I mean the OS), so I'm not aware of the latest changes.
> Right after installing it I found fontconfig is generating issues with
> some applications.  I will describe those that appeared with xterm.
> 
> Run xterm with the default system Xresources, open the "VT Fonts" dialog
> (holding down Ctrl and pressing right mouse button) check TrueType
> Fonts.  At least to me, fontconfig writes the following error:
> 
>   $ xterm
>   Fontconfig error: Cannot load default config file: No such file: (null)
> 
> Even if you implicitly set the variables the result is the same:
> 
>   $ export FONTCONFIG_FILE=/etc/fonts/fonts.conf
>   $ export FONTCONFIG_PATH=/etc/fonts
>   $ xterm -xrm xterm*renderFont:false
>   Fontconfig error: Cannot load default config file: No such file:
>   (null)

You must have caused some damage to the default installation.
Did you check that /etc/fonts/fonts.conf still exists and is readable
by everyone ? (and that the directories /etc and /etc/fonts still have
the correct mode).

> 
> Another issue I can reproduce with xterm is running it with a xft font
> and selecting in the same mentioned dialog the "Unreadable" font:
> 
>   $ xterm -fa "DejaVu Sans Mono"
>   xterm: Selected font has no valid height for ISO-8859-1 encoding
>   xterm: Selected font has no valid width for ISO-8859-1 encoding
> 
> 
> Finally, the following issue doesn't affect the mentioned bug, but cause
> some problems in some applications.  I noticed that this directory:
> 
>   /usr/X11R6/lib/X11/fonts/misc/
> 
> is *far* more populated in Debian than in OpenBSD, so I copied those fonts
> from Debian to OpenBSD, and this solved encoding errors in fvwm2, for
> example.  I don't know if those fonts were removed upstream or by some
> OpenBSD maintainer to win space.  Be aware that even when OpenBSD
> supports only UTF-8 those fonts are still needed by some applications.
> 

We removed all bitmapped fonts with encodings other than iso8859-1 and
utf8 last year.  The ISO-8859-1 are still there. I can't reproduce the
error message that you show with xterm, so either you also have a
damaged /usr/X11R6 or there is some other setting in your environment
that cauases that.

I know that some applications using libXfont2 will complain if they
can't find easter european, koi8 or iso1022-jp encoded bitmap fonts,
but we've not yet found an application in ports where these message
cause it to mal-function.

There are fonts with those encoding available in ports (and it's still
possible to package the fonts with extra encodings  in ports if there
is a real need -- but it didn't show up yet).
-- 
Matthieu Herrb

Re: X vesa driver distorted display on startup

[Matthieu Herrb]

On Tue, Jul 26, 2022 at 11:51:31PM +, Bill Chatfield wrote:

> Thank you so much. That is just the kind of information I needed to
> get me started. Yeah, it would be a fun project just for my own
> personal interest and education. I can understand you wouldn't want
> to make the kernel bigger for basically a one-off piece of old
> hardware. :-) If I can do this or something similar, maybe it'll
> teach me how to implement something that would be more useful to the
> whole community.

Back in 2015 I mentored a Google Summer of Code student on a similar
project for the Cirrus graphics cards (interesting because available
in qemu).

The code was almost finished but somehow he lost interest after the
initial GSoC period and for various reasons thw work never got merged.
It's still on-line : 
https://lab.knightsofnii.com/kristaba/openbsd (check the
cirrusdrm-current branch)

He also started some documentation on the internals there : 
http://lab.knightsofnii.com/kristaba/openbsd-drm-howto.git

*warning* : all this is 7 years old so a lot have changed in the Linux
DRM code since then and merging this code in -current is probably
more work than starting over.
-- 
Matthieu Herrb

Re: X vesa driver distorted display on startup

[Matthieu Herrb]

On Tue, Jul 26, 2022 at 04:22:46PM +, Bill Chatfield wrote:
> I apologize if this is a stupid question, but would it be possible
> to write a new driver for the i810 that works with drm/dri? I would
> be interested in giving it a try. I don't know what the blockers
> might be though. I know a GPU driver is really hard, but I believe I
> could figure it out. There's a lot of code I could reference. 
> 

Hi,

You'd need to write a *kernel* driver that presents a minimal drm/kms
interface to userland so that the modesetting X driver can be used.
the rkdrm(4) driver is an example of such a driver, although it
doesn't do any video mode management (it only uses the available mode
from the boot loader)

Another approach would be to write a bit-mapped wsdisplay(4) kernel
driver in order to use the wsfb X driver.

In both cases you need to be able to switch the i810 to graphics mode,
probe the output for supported frequencies and handle the resolution
in terms of VESA modes and present the framebuffer as a linear array
of pixels to the kernel. drm/kms offers more flexibility than
wsdisplay if you want to support a wide range of outputs (dual
monitors,... )

That said, I think the reason that it stopped working at some point
with Mesa and Linux DRM drivers is that i810 was a strange beast and
getting these simple functions to work may require some work. At some
point I had 2 machines with different variants of i810 and they each
had their own set of bugs / mis-features.

Also I think this one of the reason why the vesa X driver doesn't work
too well (or at all) on these GPUs, it may be that the BIOS vendor
didn't bother to support anything but text modes correctly. (the vesa
driver relies on the card's BIOS (well the motherboard BIOS in the
i810 case) to do all the modes management I mentionned above).

And I'm not sure there is interest to make the OpenBSD grow by some kB
to support those ancient cards. But it can be a fun project.
-- 
Matthieu Herrb

Re: Xorg segfaults -- possibly related with ws driver

[Matthieu Herrb]

On Sat, May 28, 2022 at 10:42:39AM +0100, Luis Henriques wrote:
> >Synopsis:Xorg segfauls shortly after upgrade to latest snapshot (27 May)
> >Category:system
> >Environment:
>   System  : OpenBSD 7.1
>   Details : OpenBSD 7.1-current (GENERIC.MP) #557: Fri May 27 
> 23:32:40 MDT 2022
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   Shortly after upgrading to the latest snapshot, and running 'pkg_add
>   -u', Xorg crashed.  I'm attaching the Xorg.0.log file, which seems to
>   point to a bug in ws.
> >How-To-Repeat:
>   No idea how to repeat it.
> >Fix:

Hi,

If you think my recent commit to ws.c causes this, this commit only
removes a bogus call to free() in the error path of a failed memory
allocation. You're very unlikely to have reached that code branch in a
normal situation.

Without a way to reproduce the crash and without a stack trace, it's
going to be hard to tell where the bug is or to fix it.

-- 
Matthieu Herrb

Re: NEW: Intel DRM Driver Crash

[Matthieu Herrb]

On Mon, Nov 15, 2021 at 08:37:14PM +, Lewis ingraham wrote:

> System Crashes and reboots on error. Currently on 7.0-current, I also
> wanted to note that this happens on 7.0 Release as well. Happens when
> browsing using firefox with smtube playing in the background as well as
> having htop running for system monitoring. System packages are upgraded to
> the latest version as well as system base upgraded to latest snapshot. I
> use the spectrwm window manager with these applications and options:
> picom -CG --refresh-rate 60 --backend glx --glx-no-stencil
> --unredir-if-possible --unredir-if-possible-delay 4 --no-fading-openclose
> --xrender-sync-fence --vsync
> redshift
> feh --recursive --bg-fill --randomize /home/louie/Pictures/Wallpaper/
> xfce4-terminal -e htop
> firefox
> smtube
> 
> Thank you,
> Lewis I.

Hi, in the Xorg.0.log and Xorg.0.log.old files you provided there is
no trace of an actual crash of the X server. It would be a line like
that:

(EE) Caught signal 11 (Segmentation fault). Server aborting

So this seems to indicate that its spectrwm that exited for some (bad)
reason. I've already got a report showing that jwm is causing this
kind of issue.

Could you try with another window manager (fvwm, cwm, or one from
ports) and see if you can reproduce ?

Or may be you just restarted the X server twice after a crash and lost
the Xorg.0.log.old with the actual error.

Please tell me what you can find. 
-- 
Matthieu Herrb

Re: OpenBSD/amd64: xfce screensaver/lock is not interruptible, only mouse pointer visible on blank screen, no password prompt

[Matthieu Herrb]

On Mon, Nov 15, 2021 at 11:50:41AM +0100, Peter N. M. Hansteen wrote:
> On Sun, Nov 14, 2021 at 12:25:45PM +0100, Matthieu Herrb wrote:
> > On Sun, Nov 14, 2021 at 10:44:40AM +0100, Peter N. M. Hansteen wrote:
> > > On Sat, Nov 13, 2021 at 12:16:22PM +0100, Matthieu Herrb wrote:
> > > > 
> > > > did I miss something or is this still pending ? 
> > > 
> > > I just tested, the problem unfortunately persists.
> > 
> > Strange, it works for me... At least with Landry's patch the new
> > package should display the unlock dialog now that
> > /usr/local/libexec/xfce4-screensaver-dialog is not setuid anymore...
> > 
> > Are you sure you built and installed the patched
> > xfce4-screensaver--4.16.0p0 package ?
> > 
> > Is  /usr/local/libexec/xfce4-screensaver-ask-pass properly installed
> > setgid auth ? are you using 'nosuid' on you /usr/local/partition ?
> > 
> > Sorry for the newbie -like questions...

> 
> A few oddities. My /usr/local was not nosuid, so I added the nosuid
> option to that partition's line in /etc/fstab and rebooted.

Hmm no, to have a chance to get a working xfce4-screensaver,
/usr/local should *not* be mounted nosuid (ie it should be mounted
suid, which is the default when no option is present).

> 
> After the 5 minute timeout the screensaver kicked in and touching Ctrl
> gave me a password dialog, which however did not actually accept my password.
>
> Looking for the xfce4-screensaver-ask-pass binary I do not find it at all
> on my system. That's a bit odd isn't it?

Ok so you probably didn't install the patched version. And with
/usr/local mounted nosuid, the default helper
/usr/local/libexec/xfce4-screensaver-dialog starts (since its suid bit
is now ignored, and that was the root of the issue).

So to summarize: you should rebuild and install the patched version to
test.

cd /usr/ports/x11/xfce4/xfce4-screensaver
patch -p0 -E < /this/patch
doas make clean=all
doas make package FETCH_PACKAGES=
doas make install

I'm adding Landry's patch below for reference :

-- 
Matthieu Herrb
? patchesno
? xfce4-screensaver-askpass.diff
Index: Makefile
===
RCS file: /cvs/ports/x11/xfce4/xfce4-screensaver/Makefile,v
retrieving revision 1.11
diff -u -r1.11 Makefile
--- Makefile	3 Jan 2021 17:34:23 -	1.11
+++ Makefile	1 Nov 2021 10:53:53 -
@@ -3,6 +3,7 @@
 COMMENT =	Xfce4 screensaver
 
 XFCE_GOODIE =	xfce4-screensaver
+REVISION =	0
 
 # GPLv2
 PERMIT_PACKAGE =	Yes
@@ -32,7 +33,13 @@
 
 FAKE_FLAGS =	menudir=${PREFIX}/share/examples/xfce4-screensaver/xdg/menus
 
+CONFIGURE_ARGS +=	--with-passwd-helper=${LOCALBASE}/libexec/xfce4-screensaver-ask-pass
+
+post-build:
+	${CC} ${CFLAGS} ${FILESDIR}/ask-pass.c -o ${WRKBUILD}/ask-pass
+
 post-install:
+	${INSTALL_PROGRAM} ${WRKBUILD}/ask-pass ${PREFIX}/libexec/xfce4-screensaver-ask-pass
 	@mv ${WRKINST}/etc/xdg/autostart \
 		${PREFIX}/share/examples/xfce4-screensaver/xdg/autostart
 	rm -Rf ${WRKINST}/etc/xdg
Index: files/ask-pass.c
===
RCS file: files/ask-pass.c
diff -N files/ask-pass.c
--- /dev/null	1 Jan 1970 00:00:00 -
+++ files/ask-pass.c	1 Nov 2021 10:53:53 -
@@ -0,0 +1,84 @@
+/* $OpenBSD$
+ * verifying typed passwords with bsd_auth(3)
+ *
+ * Copyright (c) 2009 Antoine Jacoutot 
+ * Copyright (c) 2021 Landry Breuil 
+ * Copyright (c) 2021 Natanael Copa 
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static void sighandler(int sig)
+{
+	if (sig > 0)
+		errx(sig, "caught signal %d", sig);
+}
+
+static void setup_signals(void)
+{
+	struct sigaction action;
+
+	memset((void *) , 0, sizeof(action));
+	action.sa_handler = sighandler;
+	action.sa_flags = SA_RESETHAND;
+	sigaction(SIGILL, , NULL);
+	sigaction(SIGTRAP, , NULL);
+	sigaction(SIGBUS, , NULL);
+	sigaction(SIGSEGV, , NULL);
+	action.sa_handler = SIG_IGN;
+	action.sa_flags = 0;
+	sigaction(SIGTERM, , NULL);
+	sigaction(SIGHUP, , NULL);
+	sigaction(SIGINT, , NULL);

Re: X.org segmentation fault - snapshot amd64

[Matthieu Herrb]

On Sun, Nov 14, 2021 at 09:38:09PM -0500, David Hill wrote:
> 
> This did not help my machine:
> 
> quick gdb on Xorg.core:
> 
> Loaded symbols for /usr/X11R6/lib/modules/input/kbd_drv.so
> Reading symbols from /usr/X11R6/lib/modules/input/ws_drv.so...done.
> Loaded symbols for /usr/X11R6/lib/modules/input/ws_drv.so
> #0  thrkill () at /tmp/-:3
> 3    /tmp/-: No such file or directory.
>     in /tmp/-
> Current language:  auto; currently asm
> (gdb) bt
> #0  thrkill () at /tmp/-:3
> #1  0x0f83e0ffaaae in _libc_abort () at
> /usr/src/lib/libc/stdlib/abort.c:51
> #2  0x0f819d6b79da in OsAbort () from /usr/X11R6/bin/Xorg
> #3  0x0f819d6be7ae in AbortServer () from /usr/X11R6/bin/Xorg
> #4  0x0f819d6bcdeb in FatalError () from /usr/X11R6/bin/Xorg
> #5  0x0f819d6b4f14 in OsSigHandler () from /usr/X11R6/bin/Xorg
> #6  
> #7  0x0f83e1059394 in memcpy (dst0=Variable "dst0" is not available.
> )
>     at /usr/src/lib/libc/string/memcpy.c:103
> #8  0x0f819d516474 in ActivatePassiveGrab () from /usr/X11R6/bin/Xorg
> #9  0x0f819d51486c in CheckPassiveGrabsOnWindow () from
> /usr/X11R6/bin/Xorg
> #10 0x0f819d51682f in CheckDeviceGrabs () from /usr/X11R6/bin/Xorg
> #11 0x0f819d615537 in ProcessOtherEvent () from /usr/X11R6/bin/Xorg
> #12 0x0f819d6415af in ProcessPointerEvent () from /usr/X11R6/bin/Xorg
> #13 0x0f819d50ff40 in PlayReleasedEvents () from /usr/X11R6/bin/Xorg
> #14 0x0f819d5110c8 in ComputeFreezes () from /usr/X11R6/bin/Xorg
> #15 0x0f819d510ea3 in DeactivatePointerGrab () from /usr/X11R6/bin/Xorg
> #16 0x0f819d511926 in AllowSome () from /usr/X11R6/bin/Xorg
> #17 0x0f819d511baa in ProcAllowEvents () from /usr/X11R6/bin/Xorg
> #18 0x0f819d4ff6a4 in Dispatch () from /usr/X11R6/bin/Xorg
> #19 0x0f819d50a78c in dix_main () from /usr/X11R6/bin/Xorg
> #20 0x0f819d4f11a8 in _start () from /usr/X11R6/bin/Xorg
> #21 0x in ?? ()
> 

Thanks. Is there anything special you do to reproduce the crash ?
(application, window manager,. specific input devices ... )

The XAllowEvent() call that seem to cause it is not used by any
application in base as far as I can see. So this code path in the X
server is not tested often, but this area got quite some churn during
the 1.20 -> 21.1 release cycle...

-- 
Matthieu Herrb

Re: X.org segmentation fault - snapshot amd64

[Matthieu Herrb]

On Sun, Nov 14, 2021 at 10:19:43AM -0800, ariel a wrote:
> 
> >Synopsis:Xorg segmentation fault
> >Category:amd64
> >Environment:
>   System  : OpenBSD 7.0
>   Details : OpenBSD 7.0-current (GENERIC.MP) #87: Wed Nov 10 10:29:31 
> MST 2021
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   I believe I noticed the graphical interface stutter or slow down
>   during mouse movement just before the crash. The X server
>   crashed (see log below), dropping into the console for a moment
>   and then displaying the xenodm login screen.
> >How-To-Repeat:
>   I don't know how to repeat it. The crash seemed to happen during
>   normal system use: running graphical programs, with a monitor
>   attached, during mouse cursor movement, but has not repeated
>   itself yet. Let me know if there's something I can do to try to
>   make this repeatable.
> 
> Someone else got this on different hardware, also amd64, see
> https://marc.info/?l=openbsd-misc=163673726428574=2
> 
> Xorg.0.log.old:
> 
> [29.449] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem
>   (Operation not permitted)
>   Check that you have set 'machdep.allowaperture=1'
>   in /etc/sysctl.conf and reboot your machine
>   refer to xf86(4) for details
> [29.449]  linear framebuffer access unavailable
> [29.479] (--) Using wscons driver on /dev/ttyC4
> [29.498] 
> X.Org X Server 1.20.13
> X Protocol Version 11, Revision 0


Can you try with an /etc/X11/xorg.conf file containing just the 4
lines below ? The intel(4) driver has not been updated for a while and
is almost abandonned upstreams. Your hardware should work with
modesetting(4) too:

Section Device
Identifier "modesetting"
Driver "modesetting"
EndSection


-- 
Matthieu Herrb

Re: OpenBSD/amd64: xfce screensaver/lock is not interruptible, only mouse pointer visible on blank screen, no password prompt

[Matthieu Herrb]

On Sun, Nov 14, 2021 at 10:44:40AM +0100, Peter N. M. Hansteen wrote:
> On Sat, Nov 13, 2021 at 12:16:22PM +0100, Matthieu Herrb wrote:
> > 
> > did I miss something or is this still pending ? 
> 
> I just tested, the problem unfortunately persists.

Strange, it works for me... At least with Landry's patch the new
package should display the unlock dialog now that
/usr/local/libexec/xfce4-screensaver-dialog is not setuid anymore...

Are you sure you built and installed the patched
xfce4-screensaver--4.16.0p0 package ?

Is  /usr/local/libexec/xfce4-screensaver-ask-pass properly installed
setgid auth ? are you using 'nosuid' on you /usr/local/partition ?

Sorry for the newbie -like questions...

-- 
Matthieu Herrb

Re: OpenBSD/amd64: xfce screensaver/lock is not interruptible, only mouse pointer visible on blank screen, no password prompt

[Matthieu Herrb]

On Mon, Nov 01, 2021 at 06:53:38PM +0100, Matthieu Herrb wrote:
> On Mon, Nov 01, 2021 at 12:30:19PM +0100, Landry Breuil wrote:
> > Le Mon, Nov 01, 2021 at 12:15:01PM +0100, Matthieu Herrb a écrit :
> > > 
> > > The problem I see with this approach is that it provides a tool that
> > > make it possible to do brute-force password checking.
> > > 
> > > I think that a solution where main screensaver process keeps the setgid
> > > auth bit, forks a privileged child to do the password check and
> > > revokes it's setgid privilege is better. But I'd like hear other
> > > people on this (millert@, kn@,...)
> > 
> > Well, i'm not going to be the one writing this code :)
> 
> Looking in more details, you solution only allows to guess one's own
> password so I retract the argument above.
> 
> ok matthieu@ for your patch.
> 

Hi,

did I miss something or is this still pending ? 
-- 
Matthieu Herrb

Re: OpenBSD/amd64: xfce screensaver/lock is not interruptible, only mouse pointer visible on blank screen, no password prompt

[Matthieu Herrb]

On Mon, Nov 01, 2021 at 12:30:19PM +0100, Landry Breuil wrote:
> Le Mon, Nov 01, 2021 at 12:15:01PM +0100, Matthieu Herrb a écrit :
> > 
> > The problem I see with this approach is that it provides a tool that
> > make it possible to do brute-force password checking.
> > 
> > I think that a solution where main screensaver process keeps the setgid
> > auth bit, forks a privileged child to do the password check and
> > revokes it's setgid privilege is better. But I'd like hear other
> > people on this (millert@, kn@,...)
> 
> Well, i'm not going to be the one writing this code :)

Looking in more details, you solution only allows to guess one's own
password so I retract the argument above.

ok matthieu@ for your patch.

-- 
Matthieu Herrb

Re: OpenBSD/amd64: xfce screensaver/lock is not interruptible, only mouse pointer visible on blank screen, no password prompt

[Matthieu Herrb]

On Mon, Nov 01, 2021 at 12:00:30PM +0100, Landry Breuil wrote:
> Le Sun, Oct 31, 2021 at 10:47:36PM +0100, Landry Breuil a écrit :
> 
> > > > > > ** (xfce4-screensaver-dialog:72106): ERROR **: 21:36:25.353: Failed 
> > > > > > to
> > > > > >connect to xfconf daemon: Cannot spawn a message bus when setuid.
> > > > > > 
> > > > > > I don't know much about xfconf / dbus / setuid applications
> > > > > > interactions, but this doesn't look like something related to 
> > > > > > changes
> > > > > > in base.
> > > > > 
> > > > > Well... iirc, nothing changed between xfconf and xfce4-screensaver 
> > > > > since
> > > > > months ... ? changes in credentials passing over sockets ?
> > > > 
> > > > The error messages comes from libgio-2.0.so.4200.14 part of glib2.
> > > 
> > > https://gitlab.xfce.org/apps/xfce4-screensaver/-/issues/96
> > 
> > well, good catch. i'll come up with something adapted from
> > https://gitlab.alpinelinux.org/alpine/aports/-/commit/ee7f451b3a1b1bdcf1de4303369a0b8a152f4d73
> > for bsdauth. I guess that's a regression from glib 2.70 update then, and
> > mate-screensaver might be affected by the same issue as they share the
> > same ancestor.
> 
> That still strange because xfce4-screensaver-dialog has code for
> bsdauth, but if i try setting the binary setgid auth instead of setuid
> root, and remove the setgroups() call, glib will still complain the
> same, even if not setuid anymore..

But it's setgid, and while the error message only refers to setuid,
the glib commit  makes it clear it's any kind of elevated privileges that
make it refuse to connect.

> 
> Havent looked at mate-screensaver, but the below diff adapted from above
> seems to work in my limited testing (eg xfce4-screensaver --debug, and
> xflock4 in another term).

The problem I see with this approach is that it provides a tool that
make it possible to do brute-force password checking.

I think that a solution where main screensaver process keeps the setgid
auth bit, forks a privileged child to do the password check and
revokes it's setgid privilege is better. But I'd like hear other
people on this (millert@, kn@,...)

But whether glib will properly recognise that the process doesn't have
privileges anymore is an open question before someone has looked at
the code or tried it.
-- 
Matthieu Herrb

Re: OpenBSD/amd64: xfce screensaver/lock is not interruptible, only mouse pointer visible on blank screen, no password prompt

[Matthieu Herrb]

On Sun, Oct 31, 2021 at 09:48:53PM +0100, Landry Breuil wrote:
> Le Sun, Oct 31, 2021 at 09:39:35PM +0100, Matthieu Herrb a écrit :
> > On Fri, Oct 29, 2021 at 10:33:04AM +0200, Peter N. M. Hansteen wrote:
> > > On Fri, Oct 29, 2021 at 10:05:34AM +0200, Landry Breuil wrote:
> > >  
> > > > i can confirm i've seen this when upgrading my machines, and most of
> > > > them were previously running various snapshots from beginning of
> > > > september/end of september, so likely a regression from "something" in X
> > > > or drm ?
> > > 
> > > I think we can narrow it down to some time this week. If I remember 
> > > correctly,
> > > I did not see this after upgrading to whatever was the latest snap late 
> > > last Sunday afternoon CEST, but I noticed this first yesterday morning 
> > > after my late Wednesday evening CEST upgrade.
> > > 
> > > The problem persists after upgrading to this morning's snap, ie
> > > 
> > > index.txt   29-Oct-2021 02:191690
> > > 
> > 
> > Ktracing the screensaver process shows it execs
> > /usr/local/libexec/xfce4-screensaver-dialog
> > which fails with the following error:
> > 
> > ** (xfce4-screensaver-dialog:72106): ERROR **: 21:36:25.353: Failed to
> >connect to xfconf daemon: Cannot spawn a message bus when setuid.
> > 
> > I don't know much about xfconf / dbus / setuid applications
> > interactions, but this doesn't look like something related to changes
> > in base.
> 
> Well... iirc, nothing changed between xfconf and xfce4-screensaver since
> months ... ? changes in credentials passing over sockets ?

The error messages comes from libgio-2.0.so.4200.14 part of glib2.

-- 
Matthieu Herrb

Re: OpenBSD/amd64: xfce screensaver/lock is not interruptible, only mouse pointer visible on blank screen, no password prompt

[Matthieu Herrb]

On Fri, Oct 29, 2021 at 10:33:04AM +0200, Peter N. M. Hansteen wrote:
> On Fri, Oct 29, 2021 at 10:05:34AM +0200, Landry Breuil wrote:
>  
> > i can confirm i've seen this when upgrading my machines, and most of
> > them were previously running various snapshots from beginning of
> > september/end of september, so likely a regression from "something" in X
> > or drm ?
> 
> I think we can narrow it down to some time this week. If I remember correctly,
> I did not see this after upgrading to whatever was the latest snap late 
> last Sunday afternoon CEST, but I noticed this first yesterday morning 
> after my late Wednesday evening CEST upgrade.
> 
> The problem persists after upgrading to this morning's snap, ie
> 
> index.txt   29-Oct-2021 02:191690
> 

Ktracing the screensaver process shows it execs
/usr/local/libexec/xfce4-screensaver-dialog
which fails with the following error:

** (xfce4-screensaver-dialog:72106): ERROR **: 21:36:25.353: Failed to
   connect to xfconf daemon: Cannot spawn a message bus when setuid.

I don't know much about xfconf / dbus / setuid applications
interactions, but this doesn't look like something related to changes
in base.

-- 
Matthieu Herrb

Re: X windows dont boot up all the way

[Matthieu Herrb]

On Tue, Aug 03, 2021 at 02:55:20AM +, Brian Alston wrote:
> Please send me a message back.
> I just want to know if you got my
> email. Sorry sendbug didn't work.
> Thanks for all your help

Hi,

The attachment in your message is mangled (embedded in an RTF file or
something).

Anyways it looks like ypu're trying to run OpenBSD/i386 on a machine
that's capable of running the 64 bits (amd64) version.

There are known issues with OpenBSD/i386 in this kind of situation. So
try to install OpenBSD/amd64 instead and report back.

-- 
Matthieu Herrb

Re: [macppc] pixman causes SIGILLs if AltiVec is not supported

[Matthieu Herrb]

On Sat, Jun 12, 2021 at 11:31:28PM -0600, Theo de Raadt wrote:
> Why not wrap all the ppc_altivec = 1 lines in #ifdef ALTIVEC
> 
> Or at the end of cpuattach, #ifndef ALTIVEC, zero the variable.
> 
> Obviously the sysctl should indicate 0, if the code support is missing.
> The sysctl isn't exposing if the cpu has the feature; it is exposing
> of the cpu+kernel have all the required support..

I'm suggesting the patch below to force machdep.altivec=0 if kernel
support is not there.

With this patch on a kernel without 'option ALTIVEC', the pixman
tests pass (while they get SIGILL without the patch)

PS: To run the pixman tests, build pixman with make -f
Makefile.bsd-wrapper and then: cd obj/tests ; make check
(the tests are sorted by run time and running all of them can take
hours; I've interrupted them after cover-test)

Index: cpu.c
===
RCS file: /cvs/OpenBSD/src/sys/arch/macppc/macppc/cpu.c,v
retrieving revision 1.83
diff -u -p -u -r1.83 cpu.c
--- cpu.c   29 May 2020 04:42:24 -  1.83
+++ cpu.c   13 Jun 2021 06:23:38 -
@@ -275,6 +275,9 @@ cpuattach(struct device *parent, struct 
snprintf(cpu_model, sizeof(cpu_model), "Version %x", cpu);
break;
}
+#ifndef ALTIVEC/* altivec support absent from kernel */
+   ppc_altivec = 0;
+#endif
snprintf(cpu_model + strlen(cpu_model),
sizeof(cpu_model) - strlen(cpu_model),
" (Revision 0x%x)", pvr & 0x);

-- 
Matthieu Herrb

Re: [macppc] pixman causes SIGILLs if AltiVec is not supported

[Matthieu Herrb]

On Sat, Jun 12, 2021 at 02:14:58PM +, Charlene Wendling wrote:
> Hi,
> 
> I've built a macppc kernel without the ALTIVEC option on one of my G4s
> to test a port fix for G3s [0], and as i'm testing some ports i've
> opened a can of worms that is leading me to pixman. Namely, i run:
>

Hi,

is that with the update to pixman 0.40 that I posted last week or so,
or the 0.38.4 version from -current ? (but normally it doesn't
matter).



> kern.version=OpenBSD 6.9-current (NOALTIVEC) #1: Fri Jun 11 19:47:02
> 
> If i run www/midori, i get that backtrace:
> 
> > $ env DISPLAY=:0 egdb midori
> > Reading symbols from midori...done.
> > (gdb) run
> > [...]
> > Thread 1 received signal SIGILL, Illegal instruction.
> > (gdb) bt
> > #0  0xf05f9b84 in vec_lvsl(int, unsigned int const*) (__a=0,
> > __b=0xfffb69a0) at /usr/lib/clang/11.1.0/include/altivec.h:4047
> > #1  vmx_combine_over_u_mask (dest=0xd52a64f0, src=0xfffb6980,
> > mask=0xfffb69a0, width=6) at pixman-vmx.c:236
> > #2  0xf05ed7e4 in vmx_combine_over_u (imp=0xe91ba000, #op=PIXMAN_OP_OVER,
> > dest=0xd52a64f0, src=0xfffb6980, mask=0xfffb69a0, width=6) at
> > pixman-vmx.c:277
> > #3  0xf05cadf8 in general_composite_rect (imp=0xe91c7000,
> > #info=0xfffbc9e8 at pixman-general.c:223
> > #4  0xf03aa4e4 in pixman_image_composite32 (op=PIXMAN_OP_OVER,
> > src=0xd5cbbe00, mask=0xc4c1a900, dest=0xcd40c300, src_x=192,
> > src_y=219, mask_x=0, mask_y=0, dest_x=28, dest_y=6, width=6,
> > height=1) at pixman.c:700
> > #5  0xe9247468 in _inplace_spans () from /usr/local/lib/libcairo.so.13.0
> 
> It looks to me it's heading to pixman/pixman-implementation.c, but it's
> not built with "-maltivec -mabi=altivec" (see the build log [1]), so i
> am assuming i'm wrong and going nowhere.

Normally from my build logs on macppc configure is probing for
VMX/Altivec:

checking whether to use VMX/Altivec intrinsics... yes

and then sets

VMX_CFLAGS='-maltivec -mabi=altivec'

for the build.

If it's not the case it probably means that removing 'option ALTIVEC'
from the kernel is not equivalent to running on a G3 machine.

I'm not sure we should support building pixman on kernel without
ALTIVEC.

And finally, looking at this remined me of the commit message for
pixman/pixmman-vmx.c 1.9 :

 | revert pixman-vmx.c to the version of pixman-0.32.8.
 | gcc 4.2 is not able to compile the new version.
 | XXX switch back to 0.34 once macppc switches to clang.

I need to check that too ... before committing 0.40...

-- 
Matthieu Herrb

Re: ASUS ZenBook X freezes

[Matthieu Herrb]

On Thu, May 20, 2021 at 09:53:02AM +0200, Peter N. M. Hansteen wrote:
> On Thu, May 20, 2021 at 08:53:14AM +1000, Jonathan Gray wrote:
> > On Wed, May 19, 2021 at 06:32:01PM +0200, Peter N. M. Hansteen wrote:
> > > On Wed, May 19, 2021 at 04:43:44PM +0200, Peter N. M. Hansteen wrote:
> > > > > outdated...)
> > > > 
> > > > I tried the first, that only seemed to have the effect of having
> > > > the freeze come faster. So I commented out that part of the xorg.conf
> > > > and I'm trying the steps in the README now, but for some reasons I
> > > > don't get any dumps in /var/crash as expected. Then again I could well
> > > > be missing some crucial step.
> > > 
> > > Still no luck getting coredumps but when I sshed in after the last freeze
> > > the last two lines of dmesg were 
> > > 
> > > [drm] *ERROR* ring sdma0 timeout, signaled seq=110053, emitted seq=110053
> > > [drm] *ERROR* Process information: process  pid 0 thread  pid 0
> > > 
> > > the [drm] part has me suspect this is related (but I don't know what sdma
> > > signifies in this context)
> > 
> > sdma is the asynchronous System DMA engine
> > 
> > Ring timeouts like this are a known problem with amdgpu which persist
> > across multiple major drm versions.
> 
> Looking at what appears in the log (/var/log/messages) the time when X
> freezes corresponds very well with when those messages are recorded.
> 
> The question is, how do I usefully debug this? I've gone over the README's 
> procedure a few times now and it unfortunately does not produce any coredumps
> or traces.

When the X server is locked up I can still ssh into the machine and
attach a debugger to the running process. I've got a few backtraces
from that, but without full symbols it's even harder to understand
what's going on.

I suspect issues with our futex implementation; in every case I find
one thread stuck in a drm ioctl while others are blocked on futex
waits.

Running an X server + Mesa fully built with debug symbols seem to make
the issue less frequent and when it happenned I didn't have time to
launch a debugger on it so far...


> 
> One option is of course to trade up or sideways to something like
> https://www.power.no/data-og-tilbehoer/pc-og-mac/baerbar-pc/asus-zenbook-s-ux393ea-pure2-13-laptop/p-1115705/
> (Intel Core i7-1165G7 with Iris Xe graphics), but would that have a better
> chance of success (or for that matter be helpful to the project)?

Which window manager / desktop environment are you using ? I've tried
to back to WindowMaker (from xfwm4) and it also seems to not trigger
the lock ups on a Ryzen Vega. But it hasn't been long enough. Sometime
I can run for days without a lockup and sometimes it locks up after
minutes.

BTW this also leads me to wonder if KARL could have an impact on the
issue in case there is some un-initialized memory access somewhere in
the code...


> 
> All the best,
> Peter
> 
> -- 
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

-- 
Matthieu Herrb

Re: ASUS ZenBook X freezes

[Matthieu Herrb]

On Wed, May 19, 2021 at 11:30:17AM +0200, Peter N. M. Hansteen wrote:

Hi,

As a workaround, can you try to force the use of the "modesetting"
driver, creating a /etc/X11/xorg.conf containing just:

Section "Device"
Identifier "amdgpu-modesetting"
Driver "modesetting"
EndSection

Otherwise if you have time for tihs, can you try to get an X
backtrace, (see /usr/xenocara/README for instructions, possibly
outdated...)

-- 
Matthieu Herrb

Re: xenodm does not use Xsetup if autoLogin is set

[Matthieu Herrb]

On Sat, Feb 20, 2021 at 08:23:17PM +, cho...@jtan.com wrote:
> The lack of Xsetup might be desired functionality but that's contrary
> to xenodm(1):
> 
>  After resetting the X server, xenodm runs the Xsetup script
>  to assist in setting up the screen the user sees along with
>  the xlogin widget.
> 
>  The xlogin widget, which xenodm presents, offers the familiar
>  login and password prompts, unless autoLogin is set.
> 
>  After the user logs in, xenodm runs the Xstartup script as
>  root.
> 
> The patch below makes this happen as per the documentation. Note
> that for anybody using autoLogin this will have a material change
> to their desktop environment as the default Xsetup script runs
> xconsole (and xsetroot).
> 
> Incidentally the reason for 'if (!d->grabServer)' is explained in
> GreetUser() that's used when autoLogin is NOT set but I felt it
> wasn't necessary to duplicate the comment.

I would prefer to fix the manual page to explain that in the autologin
case, the Xsetup script is not run.


Index: man/xenodm.man
===
RCS file: /cvs/OpenBSD/xenocara/app/xenodm/man/xenodm.man,v
retrieving revision 1.12
diff -u -p -u -r1.12 xenodm.man
--- man/xenodm.man  8 Mar 2021 17:54:28 -   1.12
+++ man/xenodm.man  13 Mar 2021 09:58:09 -
@@ -102,20 +102,23 @@ own login window, can be affected by set
 .Pa Xresources
 file.
 .Pp
-After resetting the X server,
+If
+.Ic autoLogin
+is not set (the default), after resetting the X server,
 .Nm
 runs the
 .Pa Xsetup
 script to assist in setting up the screen the user sees along with the
-xlogin widget.
-.Pp
-The xlogin widget, which
+xlogin widget which
 .Nm
-presents, offers the familiar login and password prompts, unless
+presents.
+The xlogin widget offers the familiar login and password prompts.
+.PP
+If
 .Ic autoLogin
-is set.
+is set the designated user is automatically logged in.
 .Pp
-After the user logs in,
+After the user logged in,
 .Nm
 runs the
 .Pa Xstartup

-- 
Matthieu Herrb

Re: Errors with radeon graphic card after install 68- xenodm won't work

[Matthieu Herrb]

On Mon, Oct 26, 2020 at 07:24:47PM +1100, Jonathan Gray wrote:
> On Sun, Oct 25, 2020 at 09:45:53PM +0100, Jean-Louis ABRAHAM wrote:
> > Dear OpenBSD Team
> > 
> >  
> > 
> > This mail has been generated with sendbug and I have manually added some 
> > attachments to give as much infos as possible.
> > 
> > Of course, if you need more infos, please let me know.
> > 
> > Just hope my issue is not due to not reading the docs...
> > 
> >  
> > 
> > Regards
> > 
> > Jean-Louis
> > 
> >  
> > 
> > >Synopsis:    X error with radeon graphic card - xenodm won't work
> > >Category:    amd64 xenodm
> > >Environment:
> >     System  : OpenBSD 6.8
> >     Details : OpenBSD 6.8 (GENERIC.MP) #98: Sun Oct  4 18:13:26 MDT 2020
> >              
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> >     Architecture: OpenBSD.amd64
> >     Machine : amd64
> > >Description:
> >     xenodm doesn't work; xenodm.log and X.org.log contain error messages.
> > >How-To-Repeat:
> >     at each reboot xenodm fails. However startx works.
> 
> > [drm] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD)
> > [drm] *ERROR* radeon: cp isn't working (-22).
> > drm:pid0:r100_startup *ERROR* failed initializing CP (-22).
> > drm:pid0:r100_init *ERROR* Disabling GPU acceleration
> 
> With acceleration disabled the ati driver error path seems to result in
> X:/usr/X11R6/lib/modules/drivers/radeon_drv.so: undefined symbol 
> 'exaGetPixmapDriverPrivate'
> this may be related to
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/-/commit/c0eb5dbd9c1db6b6d5b1574bcd8c584170d7ab54

Yes that looks like the problem... We can probably merge this commit.

> 
> The modesetting driver is used with startx which is why you don't see
> that there.
> 
> I am not sure why the ring test fails on ES1000.  I had another report
> off list of it failing on a system with ES1000.

No idea here.
-- 
Matthieu Herrb

Re: cwm: setxkbmap(1) breaks cwm bindings

[Matthieu Herrb]

On Tue, Sep 29, 2020 at 11:49:11PM +0200, Klemens Nanni wrote:
> Switching the X keyboard layout to something that changes keys used
> bindings used by cwm(1) and back again breaks those bindings.
> 
> cwmrc does not matter, this is reproducible with `cwm -c /dev/null';
> it happens on my amd64 machine where I `exec cwm' from ~/.xsession, e.g.
> using xenodm(1) and it also happens on a unconfigured default
> installation on loongson which starts with fvwm where I switch into cwm
> using fvwm's left-click menu "Restart>" -> "exec cwm".
> 
> So installing OpenBSD with the "[default]" keyboard layout chosen in the
> installer and the following when running X:
> 
>   # wsconsctl -n keyboard.encoding
>   us
>   $ setxkbmap -print
>   xkb_keymap {
>   xkb_keycodes  { include "xfree86+aliases(qwerty)"   };
>   xkb_types { include "complete"  };
>   xkb_compat{ include "complete"  };
>   xkb_symbols   { include 
> "pc+us+inet(pc105)+terminate(ctrl_alt_bksp)"};
>   xkb_geometry  { include "pc(pc105)" };
>   };
> 
> In cwm, I can press M-slash to "Search for windows" according to the
> manual and this just works.
> 
> When I switch to a german layout (e.g. to type "ö" without compose keys)
> like this:
> 
>   $ setxkbmap de
>   # wsconsctl -n keyboard.encoding
>   us
> 
> I can type them expected (while the wsconsctl switch stays the same) and
> M-slash also still works (while the slash is now on a different key);
> so far so good and as expected.  Other keybindings seem to work as well
> (with de mappings), but I have not tested exhaustively.
> 
> Switching back to the previous us keymap in X properly changes the
> mapping back in all my X clients and according to setxkbmap(1) is it the
> same as before switching to de:
> 
>   $ setxkbmap de
>   # wsconsctl -n keyboard.encoding
>   us
>   $ setxkbmap -print
>   xkb_keymap {
>   xkb_keycodes  { include "xfree86+aliases(qwerty)"   };
>   xkb_types { include "complete"  };
>   xkb_compat{ include "complete"  };
>   xkb_symbols   { include 
> "pc+us+inet(pc105)+terminate(ctrl_alt_bksp)"};
>   xkb_geometry  { include "pc(pc105)" };
>   };
> 
> But what is no longer working from now is the M-slash keybinding in cwm
> to search for windows.  Note that the slash is back where is belongs in
> the us keymap and typing text is expected, just cwm and this particular
> keybinding is messed up.
> 
> To get keybindings working with the us keymap again, I need to restart
> cwm - either through restarting X/xenodm or by reexecuting cwm from
> within cwm itself through its CM-w keybinding.
> 
> After reexecution and no further keymap tinkering the M-slash keybinding
> works again.
> 
> I guess wsconsctl should be used anyway, but using setxkbmap happened
> out of muscle memory and so I noticed this bug rather by accident;
> that's the first time I've been changing encodings/layouts/keymaps in
> years.
> 
> Do perhaps wsconsctl and setxkbmap conflict by design?

X is using raw keycodes from wscons, which are not dependant on the
layout and translates them to keysyms depending on the XKB
configuration.

wsconsctl is for the console. X only looks at the current wsconsctl
seting on startup to set the initial XKB config.

IF you change wsconsctl settings while X is running it should have no
effect.  And setxkbmap should have no effect on the wsconsctl settings
either.

Could you check with xev which keysyms are produced by M-slash before
and after changing the XKB config ?

-- 
Matthieu Herrb

tcpdump 'ip6' filter doesn't work on wg0 (wireguard)

[Matthieu Herrb]

Hi,

Trying to look at IPv6 traffic on my wireguard VPN with

tcpdump -n -i wg0 ip6

also shows all IPv4 traffic. Other interfacees seem to filter the v6
protocol correctly.

Any suggestion before I try to dig into the kernel code (which I'm not
really familiar with) ?

-- 
Matthieu Herrb

Re: xconsole apparently crashing in Xsetup_0?

[Matthieu Herrb]

On Wed, Jul 01, 2020 at 06:34:35PM -0400, Joe Gidi wrote:
> Hello,
> 
> I just noticed this today after upgrading to the latest amd64 snapshot,
> but honestly it may have begun some time ago. I log in almost reflexively
> and seldom pay much attention to the xenodm display.
> 
> When X starts, I see a *very* brief flicker of xconsole at the
> bottom-right of the screen before it disappears. I can then log in
> normally at the regular xenodm prompt.
> 
> I see this in the xenodm.log file:
> 
> =
> 
> xenodm info (pid 4097): Starting
> xenodm info (pid 4097): Starting X server on :0
> 
> X.Org X Server 1.20.8
> X Protocol Version 11, Revision 0
> Build Operating System: OpenBSD 6.7 amd64
> Current Operating System: OpenBSD xeon.irascible.net 6.7 GENERIC.MP#319 amd64
> Build Date: 01 July 2020  02:44:22PM
> 
> Current version of pixman: 0.38.4
> Before reporting problems, check http://wiki.x.org
> to make sure that you have the latest version.
> Markers: (--) probed, (**) from config file, (==) default setting,
> (++) from command line, (!!) notice, (II) informational,
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jul  1 18:05:21 2020
> (==) Using system config directory "/usr/X11R6/share/X11/xorg.conf.d"
> (II) modeset(0): Initializing kms color map for depth 24, 8 bpc.
> xenodm info (pid 60500): sourcing /etc/X11/xenodm/Xsetup_0
> X connection to :0 broken (explicit kill or server shutdown).
> xenodm info (pid 60500): sourcing /etc/X11/xenodm/GiveConsole
> xenodm info (pid 97106): executing session /etc/X11/xenodm/Xsession
> 
> =
> 
> Note the "X connection to :0 broken (explicit kill or server shutdown)."
> right after Xsetup_O is sourced. Any thoughts on running down the root of
> the problem?

Hi,

Thanks for the report. I can see that too on one of my machine. It
seems to be cause by a race of some sort, but I've failed to figure
out exactly what happens. Adding debugging output tends to make the
issue disapear...

The patch below which moves the launch of xconsole after setting the
background fixes the issue for now.

Index: Xsetup_0
===
RCS file: /cvs/OpenBSD/xenocara/app/xenodm/config/Xsetup_0,v
retrieving revision 1.7
diff -u -r1.7 Xsetup_0
--- Xsetup_028 Jun 2020 15:40:48 -  1.7
+++ Xsetup_02 Jul 2020 19:26:02 -
@@ -1,9 +1,9 @@
 #!/bin/sh
 # $OpenBSD: Xsetup_0,v 1.7 2020/06/28 15:40:48 matthieu Exp $
 
-xconsole -geometry 480x130-0-0 -daemon -notify -verbose -fn fixed -exitOnFail
-
 xsetroot -fg \#6f6f6f -bg \#bfbfbf -bitmap 
/usr/X11R6/include/X11/bitmaps/root_weave
+
+xconsole -geometry 480x130-0-0 -daemon -notify -verbose -fn fixed -exitOnFail
 
 #  install package openbsd-backgrounds
 #  then uncomment:

Can you confirm it ?

-- 
Matthieu Herrb

Re: Corrupted text background color on VirtualBox

[Matthieu Herrb]

On Sat, May 16, 2020 at 05:59:06PM +1000, Jonathan Gray wrote:
>

That fixes the console background issue for me on a KVM / virt-manager
virtual machine.

> Index: vga.c
> ===
> RCS file: /cvs/src/sys/dev/ic/vga.c,v
> retrieving revision 1.69
> diff -u -p -r1.69 vga.c
> --- vga.c 17 Jun 2017 19:20:30 -  1.69
> +++ vga.c 16 May 2020 07:21:19 -
> @@ -1213,8 +1213,6 @@ vga_save_palette(struct vga_config *vc)
>   vga_raw_write(vh, VGA_DAC_READ, 0x00);
>   for (i = 0; i < 3 * 256; i++)
>   *palette++ = vga_raw_read(vh, VGA_DAC_DATA);
> -
> - vga_raw_read(vh, 0x0a); /* reset flip/flop */
>  }
>  
>  void
> @@ -1231,10 +1229,6 @@ vga_restore_palette(struct vga_config *v
>   vga_raw_write(vh, VGA_DAC_WRITE, 0x00);
>   for (i = 0; i < 3 * 256; i++)
>   vga_raw_write(vh, VGA_DAC_DATA, *palette++);
> -
> - vga_raw_read(vh, 0x0a);     /* reset flip/flop */
> -
> - vga_enable(vh);
>  }
>  
>  void

-- 
Matthieu Herrb

Re: gzopen in src/lib/libz and empty files

[Matthieu Herrb]

On Fri, Apr 17, 2020 at 01:47:07AM +0200, Ingo Schwarze wrote:
> 
> The code in /usr/xenocara/lib/freetype/src/gzip/ is a completely
> different codebase written by other authors.

Hi,

For completeness, note that the zlib implementation there is not
used. We're linking libfreetype against the system libz for the actual
decompression code.  (ie FT_CONFIG_OPTION_USE_ZLIB is defined in
ftoption.h)

-- 
Matthieu Herrb

Re: xenodm(1) fails to start X(7)

[Matthieu Herrb]

On Thu, Apr 02, 2020 at 04:29:10PM +0200, Marcus MERIGHI wrote:
> >Synopsis:xenodm(1) fails to start X(7)
> >Category:x11
> >Environment:
>   System  : OpenBSD 6.6
>   Details : OpenBSD 6.6-current (GENERIC.MP) #94: Wed Apr  1 17:23:43 
> MDT 2020
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   When xenodm starts, the infamous grey screen with a mouse pointer can 
>   be seen for a glimpse, vanishes and re-appears, in a loop.
>   "doas startx" works.
> Two additional files attached: 
> Xorg.0.log.boot normal boot with xenodm trying to start X.
> Xorg.0.log.startx no xenodm, X started with "doas startx"
> This machine gets updated to latest -current often, mostly
> daily. the regression can't be very old. 
> >How-To-Repeat:
>   rcctl enable xenodm; rcctl start xenodm
> >Fix:
>   unknown.

Hi,

can you send us the contents of /var/log/xenodm.log for the looping X
server case  ? I looks like xenodm fails to start the login widget for
some reason. There may be some information there.

You can also try to run xenodm -debug 255 > xenodm.log 2>&1 as root
and look at / send the resulting log file.

-- 
Matthieu Herrb

Re: X starts on sparc64, but will not output video with XVR-600.

[Matthieu Herrb]

se: minimum y position: 0
[  2043.173] (II) ws: /dev/wsmouse: maximum y position: 1023
[  2043.173] (==) ws: /dev/wsmouse: Buttons: 7
[  2043.203] (**) ws: /dev/wsmouse: YAxisMapping: buttons 4 and 5
[  2043.204] (II) XINPUT: Adding extended input device "/dev/wsmouse" (type: 
MOUSE, id 7)
[  2043.207] (**) /dev/wsmouse: (accel) keeping acceleration scheme 1
[  2043.207] (**) /dev/wsmouse: (accel) acceleration profile 0
[  2043.208] (**) /dev/wsmouse: (accel) acceleration factor: 2.000
[  2043.208] (**) /dev/wsmouse: (accel) acceleration threshold: 4

-- 
Matthieu Herrb

Re: X window system will not start on fresh 6.6 and snapshot install

[Matthieu Herrb]

On Fri, Jan 24, 2020 at 11:47:02PM -0600, David Savolainen wrote:
Hi,

> Here is the output from sendbug.  Mail isn't fully set up..
> >Fix: What is undefined symbol 'shadowDamage'?


It's an oversight. We missed the removal from this function in xserver
back in 2016. I don't have the hardware to test it anymore.

The patch below should fix it:

Index: driver/xf86-video-wildcatfb/src/wildcatfb_driver.c
===
RCS file: 
/cvs/OpenBSD/xenocara/driver/xf86-video-wildcatfb/src/wildcatfb_driver.c,v
retrieving revision 1.13
diff -u -p -u -r1.13 wildcatfb_driver.c
--- driver/xf86-video-wildcatfb/src/wildcatfb_driver.c  30 Jun 2019 17:10:24 
-  1.13
+++ driver/xf86-video-wildcatfb/src/wildcatfb_driver.c  25 Jan 2020 14:57:33 
-
@@ -971,7 +971,7 @@ WildcatFBShadowUpdate(ScreenPtr pScreen,
 {
 ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
 WildcatFBPtr fPtr = WILDCATFBPTR(pScrn);
-RegionPtr  damage = shadowDamage (pBuf);
+RegionPtr  damage = DamageRegion (pBuf->pDamage);
 PixmapPtr  pShadow = pBuf->pPixmap;
 intnbox = REGION_NUM_RECTS (damage);
 BoxPtr pbox = REGION_RECTS (damage);


-- 
Matthieu Herrb

Re: xterm killed with pledge dns violation

[Matthieu Herrb]

On Tue, Jan 14, 2020 at 04:16:46PM +0100, Benjamin Baier wrote:
> On Tue, 14 Jan 2020 01:47:48 +0100
> Jeremie Courreges-Anglas  wrote:
> > Advertizing support for IP_ADDRESS makes little sense if we know we
> > won't implement it.  Maybe the use of #ifdef TCPCONN should be extended,
> > but I don't even know what's the deal between IP_ADDRESS and TCPCONN
> > (somehow related to xtrans).
> In this library TCPCONN == IP_ADDRESS, or better yet
> --disable-tcp-transport --> #undef TCPCONN --> no IP_ADDRESS support
> 
> Okay, we should not advertise IP_ADDRESS if we don't support it.
>

I'm removing support completely and also making a patch for upstreams.

> 
> Index: Makefile.bsd-wrapper
> ===
> RCS file: /cvs/xenocara/lib/libXmu/Makefile.bsd-wrapper,v
> retrieving revision 1.7
> diff -u -p -r1.7 Makefile.bsd-wrapper
> --- Makefile.bsd-wrapper  10 May 2019 11:44:39 -  1.7
> +++ Makefile.bsd-wrapper  14 Jan 2020 15:01:32 -
> @@ -3,6 +3,7 @@
>  SHARED_LIBS= Xmu 11.0 Xmuu 6.0
>  
>  CONFIGURE_ARGS+= --without-xsltproc --without-fop --without-xmlto
> +CONFIGURE_ARGS+= --disable-tcp-transport
>  
>  beforeinstall:
>   ${INSTALL} ${INSTALL_COPY} -o ${MANOWN} -g ${MANGRP} -m ${MANMODE} \
> Index: src/CvtStdSel.c
> ===
> RCS file: /cvs/xenocara/lib/libXmu/src/CvtStdSel.c,v
> retrieving revision 1.5
> diff -u -p -r1.5 CvtStdSel.c
> --- src/CvtStdSel.c   28 Sep 2013 17:31:53 -  1.5
> +++ src/CvtStdSel.c   14 Jan 2020 14:51:00 -
> @@ -307,16 +307,20 @@ XmuConvertStandardSelection(Widget w, Ti
>   return True;
>  }
>  if (*target == XA_TARGETS(d)) {
> -#if defined(unix)
> +#if defined(TCPCONN) && defined(unix)
>  #  define NUM_TARGETS 8
> -#else
> +#elif defined(TCPCONN) || defined(unix)
>  #  define NUM_TARGETS 7
> +#else
> +#  define NUM_TARGETS 6
>  #endif
>   Atom* std_targets = (Atom*)XtMalloc(NUM_TARGETS*sizeof(Atom));
>   int i = 0;
>   std_targets[i++] = XA_TIMESTAMP(d);
>   std_targets[i++] = XA_HOSTNAME(d);
> +#ifdef TCPCONN
>   std_targets[i++] = XA_IP_ADDRESS(d);
> +#endif
>   std_targets[i++] = XA_USER(d);
>   std_targets[i++] = XA_CLASS(d);
>   std_targets[i++] = XA_NAME(d);

-- 
Matthieu Herrb

Re: xterm killed with pledge dns violation

[Matthieu Herrb]

On Sun, Jan 12, 2020 at 02:59:46PM +0100, Benjamin Baier wrote:
> 
> Here is my status on this.
> 
> Claws-mail 3.17.4p2 has the backout diff so all the testing below was done 
> with
> claws-mail 3.17.4p1.
> 
> Following the advise from Thomas Dickey i compiled libXmu with
> CONFIGURE_ARGS+=--disable-tcp-transport
> which sets #undef TCPCONN
> which is only used once in libXmu/src/CvtStdSel.c where now the offending code
> is disabled. So this option only affects Copy actions.

Yes that prevents xterm from doing DNS resolution if asked for the IP
address of the selection owner. 
> 
> Everything fixed, everything still works with this setting.
> 
> Copy from   | Paste into| Result
> ---
> local xterm   | claws-mail| OK
> local xterm   | ssh -XY ... xterm | OK
> ssh -XY ... xterm | claws-mail| OK
> ssh -XY ... xterm | local xterm   | OK
> 
> So I will be running with the --disable-tcp-transport flag and see if I get
> other misbehaviour, but i suspect not.

Apparently claws-mail, patched to accept image pastes does the
IP_ADDRESS query for nothing (and ignores the result).

> 
> Only one other consumer in base, which is xenocara/app/xlockmore.
> The only thing I'm worried about is the 200+ ports that have an libXmu
> dependency declared.

No: it's not the consumers of XmuConvertStandardSelection() that
matter, The question is how other apps requsting the IP address of the
selection owner, and how they behave if this feature is removed from
Xmu it one way or the other.

I guess, given that there there have been no other reports since the
introdution of the xterm(1) pledges that there are no or very few
applications that cares, but at least Gtk has implemented support for
this.

The patch below tries to get an IP adress at startup (before any
pledge()) and caches it. It's also possible to not add the constructor
and always return 127.0.0.1 when queried.

And below the patch it the small test program I wrote to test how
various applications react to the different selection target
requests.

Thoughts, oks ?

Index: src/CvtStdSel.c
===
RCS file: /cvs/OpenBSD/xenocara/lib/libXmu/src/CvtStdSel.c,v
retrieving revision 1.5
diff -u -p -u -r1.5 CvtStdSel.c
--- src/CvtStdSel.c 28 Sep 2013 17:31:53 -  1.5
+++ src/CvtStdSel.c 12 Jan 2020 14:50:09 -
@@ -101,6 +101,30 @@ in this Software without prior written a
 static char *get_os_name(void);
 static Bool isApplicationShell(Widget);
 
+#ifdef __OpenBSD__
+/* Get host address in constructor to avoid doing it after pledge() */
+static uint32_t addr  = htonl(0x7f02);
+static void __attribute__((constructor)) _XmuInitIpAddress(void);
+
+static void __attribute__((constructor))
+_XmuInitIpAddress(void)
+{
+   char hostname[1024];
+   struct hostent *hostp;
+
+   hostname[0] = '\0';
+   XmuGetHostname (hostname, sizeof hostname);
+
+   if ((hostp = _XGethostbyname (hostname,hparams)) == NULL) {
+   return;
+   }
+   if (hostp->h_addrtype != AF_INET) {
+   return;
+   }
+   memmove(, hostp->h_addr, sizeof(addr));
+}
+#endif
+
 /*
  * Implementation
  */
@@ -221,6 +245,7 @@ XmuConvertStandardSelection(Widget w, Ti
 }
 #if defined(TCPCONN)
 if (*target == XA_IP_ADDRESS(d)) {
+#ifndef __OpenBSD__
char hostname[1024];
 #ifdef XTHREADS_NEEDS_BYNAMEPARAMS
_Xgethostbynameparams hparams;
@@ -240,6 +265,15 @@ XmuConvertStandardSelection(Widget w, Ti
*type = XA_NET_ADDRESS(d);
*format = 8;
return True;
+#else /* __OpenBSD__ */
+   /* return cached value */
+   *length = sizeof(addr);
+   *value = XtMalloc(sizeof(addr));
+   memcpy(*value, , sizeof(addr));
+   *type = XA_NET_ADDRESS(d);
+   *format = 8;
+   return True;
+#endif
 }
 #endif
 if (*target == XA_USER(d)) {


--8<------
/*
 * Copyright (c) 2020 Matthieu Herrb 
 *
 * Permission to use, copy, modify, and distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 * copyright notice and this permission notice appear in all copies.
 *
 * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
 * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
 * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 */

/* cc -I/usr/X11R6/include -g -Wall tsel.c \
   -L/usr/X11R6/lib

Re: xterm killed with pledge dns violation

[Matthieu Herrb]

On Sat, Jan 11, 2020 at 05:47:05PM +, Stuart Henderson wrote:
> On 2020/01/11 17:24, Matthieu Herrb wrote:
> > On Tue, Jan 07, 2020 at 09:00:04PM +0100, Benjamin Baier wrote:
> > 
> > Hi,
> > 
> > While I've been able to write a small application that reproduces
> > this, I can't reproduce the conversion to XA_IP_ADDRESS with
> > claws-mail. (I'm trying to test options to fix this in
> > libXmu).
> > 
> > Do you have any special configuration there ? (running over an SSH
> > tunnel, or anything that might trigger a decision to get the IP
> > address of the selection owner...)
> > 
> > Trying to find where this is done in the claws-mail/gtk+2/
> > dependencies is indeed not simple...
> > -- 
> > Matthieu Herrb
> > 
> 
> claws-mail might not be doing it any more as of package version 3.17.4p2 -
> an upstream change to pasting was backed out. Rebuild claws-mail with
> patch-src_compose_c removed if you want to confirm that.

Indeed, reverting the back out, I can reproduce the issue.
Thanks.
-- 
Matthieu Herrb

Re: xterm killed with pledge dns violation

[Matthieu Herrb]

On Tue, Jan 07, 2020 at 09:00:04PM +0100, Benjamin Baier wrote:

Hi,

While I've been able to write a small application that reproduces
this, I can't reproduce the conversion to XA_IP_ADDRESS with
claws-mail. (I'm trying to test options to fix this in
libXmu).

Do you have any special configuration there ? (running over an SSH
tunnel, or anything that might trigger a decision to get the IP
address of the selection owner...)

Trying to find where this is done in the claws-mail/gtk+2/
dependencies is indeed not simple...
-- 
Matthieu Herrb

Re: Turning off Accel crashes X11

[Matthieu Herrb]

On Wed, Nov 13, 2019 at 09:14:13PM -0500, Jon Fineman wrote:
> >Synopsis:Turning off Accel crashes X11
> >Category:System
> >Environment:
>   System  : OpenBSD 6.6
>   Details : OpenBSD 6.6-current (GENERIC.MP) #439: Fri Nov  8 
> 14:00:31 MST 2019
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   In xorg.conf setting Option "Accel" "false" causes X11 to crash
> >How-To-Repeat:
>   In /etc/X11/xorg.conf in the Device section setting:
>   Option "Accel" "false"
>   Causes X11 to crash when restarted.
> >Fix:
>   Leave the setting default.
> 

Hi,

Thanks for the report.

Could you try to get an X backtrace (following the instructions in
/usr/xenocara/README on how to get a core file, and then running egdb
from ports on it) ? or at lease provide us the /var/log/Xorg.0.log
file from a crash ?

Thanks in advance.
-- 
Matthieu Herrb

Re: xenodm resets on suspend/resume with external monitors

[Matthieu Herrb]

On Sun, Nov 03, 2019 at 12:50:07AM +0100, Klemens Nanni wrote:
> My workstation consists of a X230 with docking station featuring two
> DisplayPort as well as two DVI-D connectors.  I used to use one external
> monitor over DVI-D with a resolution of 2560x1440 next to the internal
> 1366x768 LVDS monitor just fine;  while docked, suspend and resume works
> and X keeps its screen configured without problems.
> 
> Now I set up an new external 3840x2160 (UHD) monitor to be used alone
> with the internal one being turned off while docked.  This in itself
> works:  due to hardware limitations, 4K over a single link is not
> possible, so the external monitor exports two logical monitors of
> 1920x2160 each which eventually plug into both DisplayPort connectors.
> 
> With xrandr(1) all expected modelines appear and I can configure the
> setup:
> 
>   xrandr --output LVDS-1 --off \
>   --output DP-2 --mode 1920x2160 --pos 1920x0 --rotate normal \
>   --output DP-3 --mode 1920x2160 --pos 0x0 --rotate normal
> 
> The problem that now occurs is that whenever I suspend to RAM and resume,
> xenodm will simply restart.  On the internal monitor which was turned
> off, TTY output is observed immediately upon resume until the xenodm
> login prompt appears on it - both external monitors stay blank.

Hi,

If xenodm restarts, it means that the X server crashed (or decided to
terminate itself for some reason...).

Please look at /var/log/Xorg.0.log.old for any error messages.

--
Matthieu Herrb

Re: panic: vmxnet3_getbuf: buffpanic: vmxnet3_getbuf: buffer has mbuf

[Matthieu Herrb]

On Mon, Oct 21, 2019 at 11:19:57AM +0200, Matthieu Herrb wrote:
> On Mon, Oct 21, 2019 at 09:52:57AM +0100, Stuart Henderson wrote:
> > On 2019/10/21 10:44, Matthieu Herrb wrote:
> > > I've observed this on several of our VMs after upgrading them to OpenBSD 
> > > 6.6.
> > 
> > This has been a problem for ages with no suggested ideas for what might be
> > wrong. I suggest replacing the virtual nics with e1000 if you want them to
> > actually work..
> 
> The strange thing is that the VMs have been working for me since at
> least 6.3 without ever stumbling on this problem.
> 
> On the critical VM bumping the RAM to 1024M seems to have "fixed" the
> issue. It has been running stable for almost 48h now.
> 

I've done some more experiments. It it clear now that it is caused by
memory pressure. I'm experimenting with the small memory-consuming
program below, and some printfs added (patches below too) and here is
a sample run. This is on a VM with 256MB of RAM.

#include 
#include 
#include 
#include 

int
main(int argc, char *argv[])
{
int i;
char *buf;

for (i = 0; i < 8192; i++) {
printf("malloc(%dM)\n", i);
buf = malloc(i*1024*1024);
if (buf != NULL) {
memset(buf, 0x55, i*1024*1024);
free(buf);
printf("success\n");
} else {
printf("failure\n");
exit(0);
}
}
}

Driver patch:

Index: if_vmx.c
===
RCS file: /cvs/src/sys/dev/pci/if_vmx.c,v
retrieving revision 1.50
diff -u -r1.50 if_vmx.c
--- if_vmx.c6 Aug 2019 10:54:40 -   1.50
+++ if_vmx.c21 Oct 2019 13:15:43 -
@@ -507,13 +507,17 @@
u_int slots;
 
for (slots = if_rxr_get(>rxr, NRXDESC); slots > 0; slots--) {
-   if (vmxnet3_getbuf(sc, ring))
+   if (vmxnet3_getbuf(sc, ring)) {
+   printf("getbuf error slots %d\n", slots);
break;
+   }
}
if_rxr_put(>rxr, slots);
 
-   if (if_rxr_inuse(>rxr) == 0)
+   if (if_rxr_inuse(>rxr) == 0) {
+   printf("timeout_add\n");
timeout_add(>refill, 1);
+   }
 }
 
 void
@@ -923,7 +927,7 @@
int btype;
 
if (ring->m[idx])
-   panic("vmxnet3_getbuf: buffer has mbuf");
+   panic("vmxnet3_getbuf: buffer has mbuf idx %d %p", idx, 
ring->m[idx]);
 
 #if 1
/* XXX Don't allocate buffers for ring 2 for now. */
@@ -938,9 +942,10 @@
 #endif
 
m = MCLGETI(NULL, M_DONTWAIT, NULL, JUMBO_LEN);
-   if (m == NULL)
+   if (m == NULL) {
+   printf("MCLGETI returns NULL\n");
return -1;
-
+   }
m->m_pkthdr.len = m->m_len = JUMBO_LEN;
m_adj(m, ETHER_ALIGN);
ring->m[idx] = m;

Results


MCLGETI returns NULL
getbuf error slots 9
MCLGETI returns NULL
getbuf error slots 78
MCLGETI returns NULL
getbuf error slots 93
timeout_add
MCLGETI returns NULL
getbuf error slots 93
timeout_add
MCLGETI returns NULL
getbuf error slots 14
MCLGETI returns NULL
getbuf error slots 33
MCLGETI returns NULL
getbuf error slots 55
MCLGETI returns NULL
getbuf error slots 71
MCLGETI returns NULL
getbuf error slots 81
MCLGETI returns NULL
getbuf error slots 95
timeout_add
MCLGETI returns NULL
getbuf error slots 95
timeout_add
MCLGETI returns NULL
getbuf error slots 96
timeout_add
MCLGETI returns NULL
getbuf error slots 16
MCLGETI returns NULL
getbuf error slots 38
MCLGETI returns NULL
getbuf error slots 57
MCLGETI returns NULL
getbuf error slots 78
MCLGETI returns NULL
getbuf error slots 97
timeout_add
MCLGETI returns NULL
getbuf error slots 98
timeout_add
MCLGETI returns NULL
getbuf error slots 99
timeout_add
MCLGETI returns NULL
getbuf error slots 100
timeout_add
MCLGETI returns NULL
getbuf error slots 101
timeout_add
MCLGETI returns NULL
getbuf error slots 102
timeout_add
MCLGETI returns NULL
getbuf error slots 103
timeout_add
MCLGETI returns NULL
getbuf error slots 104
timeout_add
MCLGETI returns NULL
getbuf error slots 105
timeout_add
MCLGETI returns NULL
getbuf error slots 106
timeout_add
MCLGETI returns NULL
getbuf error slots 1
MCLGETI returns NULL
getbuf error slots 63
MCLGETI returns NULL
getbuf error slots 108
timeout_add
MCLGETI returns NULL
getbuf error slots 108
timeout_add
MCLGETI returns NULL
getbuf error slots 1
MCLGETI returns NULL
getbuf error slots 52
MCLGETI returns NULL
getbuf error slots 88
MCLGETI returns NULL
getbuf error slots 109
MCLGETI returns NULL
getbuf error slots 17
MCLGETI returns NULL
getbuf error slots 70
MCLGETI returns NULL
getbuf error slots 110
timeout_add
MCLGETI return

Re: panic: vmxnet3_getbuf: buffpanic: vmxnet3_getbuf: buffer has mbuf

[Matthieu Herrb]

On Mon, Oct 21, 2019 at 09:52:57AM +0100, Stuart Henderson wrote:
> On 2019/10/21 10:44, Matthieu Herrb wrote:
> > I've observed this on several of our VMs after upgrading them to OpenBSD 
> > 6.6.
> 
> This has been a problem for ages with no suggested ideas for what might be
> wrong. I suggest replacing the virtual nics with e1000 if you want them to
> actually work..

The strange thing is that the VMs have been working for me since at
least 6.3 without ever stumbling on this problem.

On the critical VM bumping the RAM to 1024M seems to have "fixed" the
issue. It has been running stable for almost 48h now.

-- 
Matthieu Herrb

Re: X screen refresh problem in newest snapshot

[Matthieu Herrb]

On Thu, Aug 22, 2019 at 12:02:49PM +0200, pe...@bsdly.net wrote:
> >Synopsis:Screen refresh problem (current window disappears for several 
> >seconds) on newest snapshot
> >Category:X, xenocara
> >Environment:
>   System  : OpenBSD 6.6
>   Details : OpenBSD 6.6-beta (GENERIC.MP) #240: Wed Aug 21 21:00:40 
> MDT 2019
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   After sysupgrading my laptop to latest amd64 snapshot, screen refresh 
> in X is erratic. the window with
>   current focus disappears for anything up to several seconds before 
> reappearing. I assume this is related
>   to recent updates, since the problem did not appear in previous 
> snapshots (my previous was 2 days ago
>   if I remember correctly.
> >How-To-Repeat:
>   Upgrading to 21 Aug amd64 snapshot was what triggered here. No other 
> config changes done.
> >Fix:
>   To be determined.

Hi,

which desktop environment (or window manager) are you using ?
If it's XFCE, the have a look at the package readme, the part that
suggests tweking vblank_mode...

I don't see anything else significant that may have changed in the
last days (except perhaps some of the drm commits...).
-- 
Matthieu Herrb

Re: xman reports several errors after initial search

[Matthieu Herrb]

On Thu, Aug 15, 2019 at 01:26:23AM +0200, Ingo Schwarze wrote:
> Hi,
> 
> i never looked at xman(1) nor did i ever use it.
> 
> But oh gawd...
> 
> That whole thing is totally broken.
> Nothing about it works at all.
> 
> For example, try to view the strlcat(3) manual page:
> start xman(1), hit Ctrl-S, type "strlcat", click "Manual Page".
> The response is "No manual entry for strlcat".
> 
> It attempts to reimplement man(1) in a very poor way.
> It uses the old man.conf(5) format that we stopped supporting
> years ago.  I'm sure that list of issues is far from complete.
> 
> Fixing it seems like a major undertaking - and a complete waste of time.
> I'm mean, what's the point?  Just run man(1) in an xterm(1).  That
> actually works and has so much more useful features.
> 
> Consequently, i strongly suggest that we simply delete the whole
> program from OpenBSD without any replacement.  That is what we usually
> do with software that is broken, obviously unmaintained, and useless.
> 
> Any objections?
> 

None from me.
Not worth the effort to add mandoc.db support. Nowadays we can build
an electron app around man.openbsd.org if we need a replacement :)

-- 
Matthieu Herrb

Re: xserver problem with 1.19.7->1.20.5

[Matthieu Herrb]

On Thu, Aug 08, 2019 at 09:42:49AM +0200, Sebastien Marie wrote:
> On Wed, Aug 07, 2019 at 07:47:43PM +0200, Matthieu Herrb wrote:
> > On Wed, Aug 07, 2019 at 11:32:09AM +0200, Matthieu Herrb wrote:
> > > 
> > > I will also have a look on why did the extra built-in modes disapear.
> > > But I think that if you can run a better driver than xf86-video-vesa,
> > > it is better.
> > 
> > Hi again,
> > 
> > I think I've found the problem.
> > It's caused by this commit:
> > https://gitlab.freedesktop.org/xorg/xserver/commit/fdc79fe72bc0b97776df2c3a664076c60e08a87c
> > 
> > Can you try this patch to xserver 1.20.5 ?
> > 
> > The reason why xf86PruneDuplicateModes() removes modes that are not
> > duplicated is still to be identified though.
> > 
> > Index: hw/xfree86/modes/xf86EdidModes.c
> > ===
> > RCS file: /cvs/xenocara/xserver/hw/xfree86/modes/xf86EdidModes.c,v
> > retrieving revision 1.18
> > diff -u -p -u -r1.18 xf86EdidModes.c
> > --- hw/xfree86/modes/xf86EdidModes.c27 Jul 2019 07:57:17 -  
> > 1.18
> > +++ hw/xfree86/modes/xf86EdidModes.c7 Aug 2019 17:42:14 -
> > @@ -1220,8 +1220,6 @@ xf86EdidMonitorSet(int scrnIndex, MonPtr
> >  Monitor->Modes = Modes;
> >  }
> >  
> > -Monitor->Modes = xf86PruneDuplicateModes(Monitor->Modes);
> > -
> >  /* Update pointer to last mode */
> >  for (Mode = Monitor->Modes; Mode && Mode->next; Mode = Mode->next) 
> > {}
> >  Monitor->Last = Mode;
> > 
> 
> I confirm the diff solves the issue.

Thanks. I will try to debug this a bit more. I tried this with radeon,
intel and modesettings drivers. It doesn't change anything with those.


-- 
Matthieu Herrb

Re: xserver problem with 1.19.7->1.20.5

[Matthieu Herrb]

On Wed, Aug 07, 2019 at 11:32:09AM +0200, Matthieu Herrb wrote:
> 
> I will also have a look on why did the extra built-in modes disapear.
> But I think that if you can run a better driver than xf86-video-vesa,
> it is better.

Hi again,

I think I've found the problem.
It's caused by this commit:
https://gitlab.freedesktop.org/xorg/xserver/commit/fdc79fe72bc0b97776df2c3a664076c60e08a87c

Can you try this patch to xserver 1.20.5 ?

The reason why xf86PruneDuplicateModes() removes modes that are not
duplicated is still to be identified though.

Index: hw/xfree86/modes/xf86EdidModes.c
===
RCS file: /cvs/xenocara/xserver/hw/xfree86/modes/xf86EdidModes.c,v
retrieving revision 1.18
diff -u -p -u -r1.18 xf86EdidModes.c
--- hw/xfree86/modes/xf86EdidModes.c27 Jul 2019 07:57:17 -  1.18
+++ hw/xfree86/modes/xf86EdidModes.c7 Aug 2019 17:42:14 -
@@ -1220,8 +1220,6 @@ xf86EdidMonitorSet(int scrnIndex, MonPtr
 Monitor->Modes = Modes;
 }
 
-Monitor->Modes = xf86PruneDuplicateModes(Monitor->Modes);
-
 /* Update pointer to last mode */
 for (Mode = Monitor->Modes; Mode && Mode->next; Mode = Mode->next) {}
     Monitor->Last = Mode;


-- 
Matthieu Herrb

Re: xserver problem with 1.19.7->1.20.5

[Matthieu Herrb]

On Wed, Aug 07, 2019 at 09:21:28AM +0200, Sebastien Marie wrote:
> Hi,
> 
> I upgraded an amd64 host with
>   OpenBSD 6.5-current (GENERIC.MP) #174: Tue Aug 6 10:56:11 MDT 2019.
> 
> The system starts xenodm using rcctl.
> 
> With X Server 1.20.5, the maximum screen size is 720x400, whereas it was
> 1280x1024 before.
> 
> old$ xrandr
> xrandr: Failed to get size of gamma for output default
> Screen 0: minimum 640 x 400, current 1280 x 1024, maximum 1280 x 1024
> default connected 1280x1024+0+0 0mm x 0mm
>1280x1024  0.00* 
>1152x864   0.00  
>1024x768   0.00  
>800x6000.00  
>640x4800.00  
>720x4000.00  
> 
> new$ xrandr
> xrandr: Failed to get size of gamma for output default
> Screen 0: minimum 720 x 400, current 720 x 400, maximum 720 x 400
> default connected 720x400+0+0 0mm x 0mm
>720x4000.00* 
> 
> 
> I reverted X Server by untarring an old xserv65.tgz set, and I have got
> back a working X Server.
> 
> I see no change in dmesg with my old state (Thu Jul 25 08:28:22 MDT
> 2019). I attached the current dmesg below (the radeondrm0 error and
> detach was already present before).
> 
> The system uses VESA driver.

Hi,

have you installed the radeon firmware package ?  If not, that may
explain why this machine cannot use KMS and the radeon X driver.

If not, is it on purpose ?

I think I have a machine wih a Radeon HD 2400 that works well. I just
need to recheck when I'm home this evening.

I will also have a look on why did the extra built-in modes disapear.
But I think that if you can run a better driver than xf86-video-vesa,
it is better.

-- 
Matthieu Herrb

Re: cwm: libX11: SIGBUS

[Matthieu Herrb]

On Sun, Aug 04, 2019 at 04:25:03PM +0200, Klemens Nanni wrote:
> On Sun, Aug 04, 2019 at 12:40:50PM +0200, Matthieu Herrb wrote:
> > Did you try with the updates to libX11 and libXft that I sent to tech@
> > a few weeks ago ? There is one change in libXft which may be relevant.
> No, missed them.  Just fetched your updates from current CVS, rebuilt
> libX11 and libXft, but with no avail.
> 
> Same reproducer, same bug.  New backtrace below and full one attached
> (for real this time, sorry).
>

Ok. Thanks.

The 0xdfdfdf clearly shows that it's accessing a DISPLAY* that has been
free'd  But I can't tell if the bug is inside cwm, or if it's libX11/libXft
that gets confused.

I don't tink that cwm is playing games with multiple displays (Xinerama)
when you add more xrandr screens, so normally it should have only one
DISPLAY. But I may be wrong.


> 
> [New process 238882]
> Core was generated by `cwm'.
> Program terminated with signal SIGBUS, Bus error.
> #0  0x0261a2f9101d in XAddExtension (dpy=0xdfdfdfdfdfdfdfdf) at 
> /usr/xenocara/lib/libX11/src/InitExt.c:73
> 73LockDisplay (dpy);
> #0  0x0261a2f9101d in XAddExtension (dpy=0xdfdfdfdfdfdfdfdf) at 
> /usr/xenocara/lib/libX11/src/InitExt.c:73
> #1  0x026265e448f9 in _XftDisplayInfoGet () from 
> /usr/X11R6/lib/libXft.so.11.0
> #2  0x026265e46a49 in XftDrawSrcPicture () from 
> /usr/X11R6/lib/libXft.so.11.0
> #3  0x026265e470cb in XftDrawGlyphs () from /usr/X11R6/lib/libXft.so.11.0
> #4  0x026265e479dc in XftDrawStringUtf8 () from 
> /usr/X11R6/lib/libXft.so.11.0
> #5  0x025f92282fdd in menu_draw (mc=0x7f7dd570, menuq=0x7f7dd948, 
> resultq=0x7f7dd560) at /x/app/cwm/menu.c:399
> #6  0x025f9228212f in menu_filter (sc=0x26197db1000, 
> menuq=0x7f7dd948, prompt=0x25f9227849f "window", initial=0x0, flags=0, 
> match=0x25f92283f00 , print=0x25f92284b20 
> ) at /x/app/cwm/menu.c:153
> #7  0x025f9228ca16 in kbfunc_menu_client (ctx=0x26197db1000, 
> cargs=0x261ab1b6280) at /x/app/cwm/kbfunc.c:484
> #8  0x025f92288ffa in xev_handle_keypress (ee=0x7f7dda28) at 
> /x/app/cwm/xevents.c:336
> #9  0x025f9228a19d in xev_process () at /x/app/cwm/xevents.c:491
> #10 0x025f9227c63f in main (argc=0, argv=0x7f7ddbd0) at 
> /x/app/cwm/calmwm.c:114
-- 
Matthieu Herrb

Re: cwm: libX11: SIGBUS

[Matthieu Herrb]

On Sun, Aug 04, 2019 at 12:32:12PM +0200, Klemens Nanni wrote:
> Here is a reproducer as well as a complete backtrace.

Did you try with the updates to libX11 and libXft that I sent to tech@
a few weeks ago ? There is one change in libXft which may be relevant.

> 
> My current setup consists of a X230 on a docking station with one
> external monitor connected via DVI-D (shows up as HDMI-2 in xrandr).
> 
> This monitor is a bit special since it lacks proper EDID, so I have to
> add modelines manually.  The two one-liners are included here for the
> sake of completeness, but keep in mind that this crash also happens with
> a completely different setup with completely distinct monitors which do
> provide EDID and work out of the box.
> 
> Running snapshot from
> 
>   OpenBSD 6.5-current (GENERIC.MP) #170: Sat Aug  3 09:50:56 MDT 2019
>   dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> with `vm.malloc_conf=CFGSU' and cwm, libX11, libXft built with `-g3 -O0'.
> 
> Steps to reproduce:
> 
> 1. add manualmodeline
> 
>   xrandr --newmode "2560x1440_30.00"  146.27  2560 2680 2944 3328  1440 
> 1441 1444 1465  -HSync +Vsync
>   xrandr --addmode HDMI-2 2560x1440_30.00
> 
> 2. enable external monitor, keep internal one as secondary
> 
>   xrandr --output HDMI-2 --primary --rotation inverted --above LVDS-1 
> --auto --output LVDS-1
> 
> 3. run a fullscreen program (starts on primary)
> 
>   0ad
> 
> 4. while in fullscreen, press M-/ (Alt slash with default cwm)
> 
> cwm crashes and I drop to the xenodm login.
> 
> Without restarting X itself, the external monitor seemingly keeps its
> modelines configured since it continues to show all black, but it is not
> configured as part of my screen any longer.
> 
> But strangely, I can see the half of my mouse cursor showing up on it
> when moving along.  Simply rerunning step 2. to configure the screen
> fails:
> 
>   xrandr: Output HDMI-2 is not disconnected but has no modes
>   xrandr: cannot find preferred mode
> 
> Restarting X (read: xenodm) resets everything and I can run steps 1. and
> 2. to get everything working again.
> 
> My other setups include two external monitors with the internal one
> turned off, I have yet to find a reproducer that does not include a
> fullscreen program like 0ad, but it the same crash appeared there as
> well.
> 
> See backtraced below and a full version attached.
> 
> [New process 212650]
> Core was generated by `cwm'.
> Program terminated with signal SIGBUS, Bus error.
> #0  0x0bbbe340a01d in XAddExtension (dpy=0xdfdfdfdfdfdfdfdf) at 
> /usr/xenocara/lib/libX11/src/InitExt.c:73
> 73LockDisplay (dpy);
> #0  0x0bbbe340a01d in XAddExtension (dpy=0xdfdfdfdfdfdfdfdf) at 
> /usr/xenocara/lib/libX11/src/InitExt.c:73
> #1  0x0bbbd2ff48f9 in _XftDisplayInfoGet (dpy=0xdfdfdfdfdfdfdfdf, 
> createIfNecessary=1) at /usr/xenocara/lib/libXft/src/xftdpy.c:91
> #2  0x0bbbd2ff6a19 in XftDrawSrcPicture (draw=0xbbb46fd7600, 
> color=0xbbbed59cb28) at /usr/xenocara/lib/libXft/src/xftdraw.c:300
> #3  0x0bbbd2ff6fdb in XftDrawGlyphs (draw=0xbbb46fd7600, 
> color=0xbbbed59cb28, pub=0xbbbfd21f000, x=0, y=13, glyphs=0x7f7f8ad0, 
> nglyphs=8) at /usr/xenocara/lib/libXft/src/xftdraw.c:484
> #4  0x0bbbd2ff78ec in XftDrawStringUtf8 (draw=0xbbb46fd7600, 
> color=0xbbbed59cb28, pub=0xbbbfd21f000, x=0, y=13, string=0x7f7f9eeb "", 
> len=0) at /usr/xenocara/lib/libXft/src/xftdraw.c:621
> #5  0x0bb9389bdfdd in menu_draw (mc=0x7f7f9df0, menuq=0x7f7fa1c8, 
> resultq=0x7f7f9de0) at /x/app/cwm/menu.c:399
> #6  0x0bb9389bd12f in menu_filter (sc=0xbbbed59ca00, 
> menuq=0x7f7fa1c8, prompt=0xbb9389b349f "window", initial=0x0, flags=0, 
> match=0xbb9389bef00 , print=0xbb9389bfb20 
> ) at /x/app/cwm/menu.c:153
> #7  0x0bb9389c7a16 in kbfunc_menu_client (ctx=0xbbbed59ca00, 
> cargs=0xbbb9b36c780) at /x/app/cwm/kbfunc.c:484
> #8  0x0bb9389c3ffa in xev_handle_keypress (ee=0x7f7fa2a8) at 
> /x/app/cwm/xevents.c:336
> #9  0x0bb9389c519d in xev_process () at /x/app/cwm/xevents.c:491
> #10 0x0bb9389b763f in main (argc=0, argv=0x7f7fa450) at 
> /x/app/cwm/calmwm.c:114

-- 
Matthieu Herrb

Re: LibreOffice rendering issue in XFCE on OpenBSD

[Matthieu Herrb]

On Sun, Jun 23, 2019 at 01:58:06PM +0200, Mátyás Seress wrote:
> Hi,
> 
> I looked at the window manager tweaker and it turns out that compositing
> was enabled all along, so that could not have been the problem. Which
> leaves us with the vesa driver as the culprit. (For the record, I also have
> a Ubuntu VM with Gnome desktop environment which doesn't have this issue.)
> I don't actually need to do any work in LibreOffice, I'm just getting to
> know OpenBSD so that some day I might switch over to it but before I do
> that I want to familiarize myself with it. So you say if I install it
> natively it would work fine?

Probably, yes. I'm using LibreOffice regularly under OpenBSD and it
works fine most of the time.
-- 
Matthieu Herrb

Re: LibreOffice rendering issue in XFCE on OpenBSD

[Matthieu Herrb]

On Sun, Jun 23, 2019 at 01:29:07PM +0200, Mátyás Seress wrote:
> Hi Matthieu,
> 
> Sorry for the "lack of useful information", I think I lack the technical
> knowledge.
> - if I run pkg_info -Q xfwm i can see that it says it's installed (this is
> the compositor window manager, right?) And when I type xcompmgr in the
> terminal, I get this message: "Another composite manager is already running
> (Xfwm4)" So I guess I must be using some window manager...

Ok. You can check in the 'window manager tweaks' setting, the
compositor tab. Try to toggle the setting.

> - I don't know how to determine what driver my X is using in VirtualBox,
> but I attached the log you asked for, hope it helps.

The log shows that you're using the 'vesa' driver, that uses the VESA
BIOS provided by the card emulation to handle the display.

If you really need to get work done with LibreOffice, either consider
installing OpenBSD natively on your machine (so that a real
accelerated driver can be used to manage the display), or just install
an run LibreOffice on your host system.

The display under VirtualBox, without the Virtual Box extensions is
to be considered as unsupported.


-- 
Matthieu Herrb

Re: LibreOffice rendering issue in XFCE on OpenBSD

[Matthieu Herrb]

On Sun, Jun 23, 2019 at 10:09:21AM +0200, Mátyás Seress wrote:
> Hi,
> 
> I'm running OpenBSD 6.5 on a Windows 10 host in VirtualBox 5.2.30. I
> installed the XFCE desktop environment together with LibreOffice. But
> LibreOffice has an issue: some drop-down menus are not rendered correctly.
> You cannot drop them down, no matter how hard you click, only edit the text
> in them. And when you do it, the new text is rendered on top of the old
> text, like in the font size selector. Is this a known issue? Is there any
> solution? Maybe LibreOffice has not been ported very well to OpenBSD? For
> screenshots see the attachments.
> 

Hi,

While there may be an issue in LibreOffice, I think the problems are
more likely to be caused by your environment. The lack of useful
information above makes it difficult to guess.

- Do you use compositing the the XFCE window manager ? If no, you may
  try to enable it.
- Which driver is your X under VirtualBox using ? (include
  /var/log/Xorg.0.log in your report next time) OpenBSD doesn't
  provide support for the driver in VBoxUtilities on other systems, so
  you fall back to some kind hardware emulation, which may have its
  own set of bugs, or expose bugs in the driver Xorg is using on
  OpenBSD.
-- 
Matthieu Herrb

Re: xenodm issue with external screen

[Matthieu Herrb]

On Tue, May 28, 2019 at 03:20:30PM +0200, Stephane HUC "PengouinBSD" wrote:
> Hi
> 
> I encounter an issue with my laptop (dmesg after the message) when using
> an external HDMI screen.
> 
> When I start X without the external screen, everything works. And, into
> my session, if i plug this screen, it's OK, too!
> 
> If I start xenodm with the plugged external screen, once I log-in, I get
> back to xenodm login screen.

Are there any errors messages in ${HOME}/.xsession-errors ?

-- 
Matthieu Herrb

Re: syspatch fails on 6.4/amd64

[Matthieu Herrb]

On Wed, May 22, 2019 at 12:31:48AM -0700, Mike Larkin wrote:
> On Wed, May 22, 2019 at 08:46:06AM +0200, Matthieu Herrb wrote:
> > Hi,
> > 
> > The latest syspatch failed for me on one machine running syspatch:
> > 
> > $ doas syspatch
> > Get/Verify syspatch64-016_vmmints... 100% |*|   170 KB
> > 00:00
> > Installing patch 016_vmmints
> > Get/Verify syspatch64-017_rip6cks... 100% |*|   193 KB
> > 00:00
> > Installing patch 017_rip6cksum
> > Relinking to create unique kernel... failed!
> > 
> > And /usr/share/relink/kernel/GENERIC.MP/relink.log contains:
> > 
> > (SHA256) /bsd: OK
> > LD="ld" sh makegap.sh 0x
> > ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o 
> > ${OBJS}
> > vmm.o: In function `vmm_fpurestore':
> > /usr/src/sys/arch/amd64/amd64/vmm.c:3887: undefined reference to 
> > `xsetbv_user'
> > /usr/src/sys/arch/amd64/amd64/vmm.c:3887: undefined reference to 
> > `xsetbv_user'
> > /usr/src/sys/arch/amd64/amd64/vmm.c:3887: undefined reference to 
> > `xsetbv_user'
> > *** Error 1 in /usr/share/relink/kernel/GENERIC.MP (Makefile:988 'newbsd': 
> > @echo ld -T ld.script -X --warn-common -nopie -o newbsd '${SYSTEM...)
> > 
> 
> Odd. That function is present in 6.4, not sure why it isn't being found.
> 
> Can you objdump your KARL locore.o and see if xsetbv_user is there?

Hi,

xsetbv_user isn't in locore.o on this machine.

I've checked another 6.4 machine and it's definatly here. Apparently I
managed to get a pre-6.4 snapshot on the affected machine as the
locore.o file there is dated from oct 6, 2018, while on the other
(good one) it's from oct 11.

Sorry for the noise.
-- 
Matthieu Herrb

syspatch fails on 6.4/amd64

[Matthieu Herrb]

rg 0 lun 0:  SCSI3 0/direct 
fixed naa.55cd2e404be954de
sd0: 28626MB, 512 bytes/sector, 58626288 sectors, thin
ahci1 at pci0 dev 24 function 0 "Intel Atom C2000 AHCI" rev 0x02: msi, AHCI 1.3
scsibus2 at ahci1: 32 targets
pcib0 at pci0 dev 31 function 0 "Intel Atom C2000 PCU" rev 0x02
ichiic0 at pci0 dev 31 function 3 "Intel Atom C2000 PCU SMBus" rev 0x02: apic 2 
int 22
iic0 at ichiic0
iic0: addr 0x2e 00=3d words 00=3d3d 01= 02= 03= 04= 05= 
06= 07=
spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-12800 with thermal sensor
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
com1: console
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vmm0 at mainbus0: VMX/EPT (using slow L1TF mitigation)
uhub1 at uhub0 port 1 configuration 1 interface 0 "Intel product 0x07db" rev 
2.00/0.02 addr 2
uhidev0 at uhub1 port 2 configuration 1 interface 0 "Ten X Technology, Inc. 
PCsensor Temper" rev 1.10/1.50 addr 3
uhidev0: iclass 3/1
uthum0 at uhidev0
uhidev1 at uhub1 port 2 configuration 1 interface 1 "Ten X Technology, Inc. 
PCsensor Temper" rev 1.10/1.50 addr 3
uhidev1: iclass 3/0
uthum1 at uhidev1
umass0 at uhub1 port 4 configuration 1 interface 0 "Generic Ultra Fast Media" 
rev 2.00/1.98 addr 4
umass0: using SCSI over Bulk-Only
scsibus3 at umass0: 2 targets, initiator 0
sd1 at scsibus3 targ 1 lun 0:  SCSI0 0/direct 
removable serial.0424224000225001
sd1: 3776MB, 512 bytes/sector, 7733248 sectors
vscsi0 at root
scsibus4 at vscsi0: 256 targets
softraid0 at root
scsibus5 at softraid0: 256 targets
root on sd0a (d3f1a22c1d4f10ad.a) swap on sd0b dump on sd0b

-- 
Matthieu Herrb

-current on Dell Optiplex 755: panic: attempt to execute user address 0x0 in supervisor mode

[Matthieu Herrb]

1 interface 0 "Intel EHCI root hub" rev 2.00/1.=
00 addr 1
ppb2 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x92
pci3 at ppb2 bus 3
rl0 at pci3 dev 2 function 0 "D-Link DFE-530TX+" rev 0x10: apic 8 int 18, a=
ddress 1c:7e:e5:1e:14:31
rlphy0 at rl0 phy 0: RTL internal PHY
pcib0 at pci0 dev 31 function 0 "Intel 82801IO LPC" rev 0x02
ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x02: msi, AHCI 1.2
ahci0: port 0: 3.0Gb/s
ahci0: PHY offline on port 1
ahci0: PHY offline on port 2
ahci0: PHY offline on port 3
ahci0: PHY offline on port 5
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct =
fixed naa.50014ee1ac13a207
sd0: 152587MB, 512 bytes/sector, 31250 sectors
ichiic0 at pci0 dev 31 function 3 "Intel 82801I SMBus" rev 0x02: apic 8 int=
 18
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 1GB DDR2 SDRAM non-parity PC2-6400CL6
spdmem1 at iic0 addr 0x51: 1GB DDR2 SDRAM non-parity PC2-6400CL6
spdmem2 at iic0 addr 0x52: 1GB DDR2 SDRAM non-parity PC2-6400CL6
spdmem3 at iic0 addr 0x53: 1GB DDR2 SDRAM non-parity PC2-6400CL6
usb2 at uhci0: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.=
00 addr 1
usb3 at uhci1: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.=
00 addr 1
usb4 at uhci2: USB revision 1.0
uhub4 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.=
00 addr 1
usb5 at uhci3: USB revision 1.0
uhub5 at usb5 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.=
00 addr 1
usb6 at uhci4: USB revision 1.0
uhub6 at usb6 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.=
00 addr 1
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
panic: attempt to execute user address 0x0 in supervisor mode
Stopped at  db_enter+0x10:  popq%rbp
TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
db_enter(10,8000221c98c0,202,8,81817f60,8000221c98c0) at db=
_ent
er+0x10
panic(81ade306,81ade306,8000221b2bb8,8000221c4000,f=
fff8
000221c9a30,0) at panic+0x128
pageflttrap(8000221c9a30,0,fffc7b7e9fcec41a,8000221c9a30,6,0) at pa=
gefl
ttrap+0x2aa
kerntrap(8000221c9a30,8000221c9a30,c7bcebe1010315d3,0,0,81c=
fb96
0) at kerntrap+0x7c
alltraps_kern(6,81cfb960,8007ad80,10,0,0) at alltraps_kern+=
0x7b

0(8000221c9b20,8007ad80,85dc4a00f1d276b7,80073c00,f=
fff8
1725bba,0) at 0
Xintr_ioapic_level11_untramp(0,0,0,0,8001c200,800239c0) at =
Xint
r_ioapic_level11_untramp+0x1a3
acpicpu_idle(5d15791c772851f,0,81cf3ff0,0,81cf3ff0,0) at ac=
picp
u_idle+0x25e
sched_idle(81cf3ff0,81cf3ff0,0,0,81cf3ff0,8=
19dc
1a0) at sched_idle+0x1d5
end trace frame: 0x0, count: 6
https://www.openbsd.org/ddb.html describes the minimum info required in bug
--db_more--=08=08=08=08=08=08=08=08=08=08=08   =08=08=08=08=08=08=
=08=08=08=08=08reports.  Insufficient info makes it difficult to find and f=
ix bugs.
ddb> ps
   PID TID   PPIDUID  S   FLAGS  WAIT  COMMAND
 60986  446683  0  0  3 0x14200  bored crynlk
 71300  508867  0  0  3 0x14200  bored crypto
 30343  163444  0  0  3 0x14200  usbsynusbtask
 57859  483931  0  0  3 0x14200  usbatsk   usbatsk
 76044  403061  0  0  3 0x14200  bored drmtskl
 22745  238653  0  0  3 0x14200  bored drmlwq
 42318  272743  0  0  3 0x14200  bored drmubwq
 88712  136899  0  0  3 0x14200  bored drmwq
 29149  175332  0  0  3  0x40014200  acpi0 acpi0
 82958  453759  0  0  3 0x14200  bored sensors
 76688  522252  0  0  3 0x14200  bored softnet
  7574  517995  0  0  3 0x14200  bored systqmp
 89462  215024  0  0  3 0x14200  bored systq
 86134  232656  0  0  3  0x40014200  bored softclock
*41506  180042  0  0  7  0x40014200idle0
 34079  134098  0  0  3 0x14200  bored smr
 1  334494  0  0  3   0  initexec  swapper
 0   0 -1  0  3 0x10200  cfpendswapper
ddb> trace
db_enter(10,8000221c98c0,202,8,81817f60,8000221c98c0) at db=
_ent
er+0x10
panic(81ade306,81ade306,8000221b2bb8,8000221c4000,f=
fff8
000221c9a30,0) at panic+0x128
pageflttrap(8000221c9a30,0,fffc7b7e9fcec41a,8000221c9a30,6,0) at pa=
gefl
ttrap+0x2aa
kerntrap(8000221c9a30,8000221c9a30,c7bcebe1010315d3,0,0,81c=
fb96
0) at kerntrap+0x7c
alltraps_kern(6,81cfb960,8007ad80,10,0,0) at alltraps_kern+=
0x7b

0(8000221c9b20,8007ad80,85dc4a00f1d276b7,80073c00,f=
fff8
1725bba,0) at 0
Xintr_ioapic_level11_untramp(0,0,0,0,8001c200,800239c0) at =
Xint
r_ioapic_level11_untramp+0x1a3
acpicpu_idle(5d15791c772851f,0,81cf3ff0,0,81cf3ff0,0) at ac=
picp
u_idle+0x25e
sched_idle(81cf3ff0,81cf3ff0,0,0,81cf3ff0,8=
19dc
1a0) at sched_idle+0x1d5
end trace frame: 0x0, count: -9
ddb> show panic
attempt to execute user address 0x0 in supervisor mode
ddb>=20
--=20
Matthieu Herrb

Re: wscons.c chooses wrong variant for br layout

[Matthieu Herrb]

On Wed, Apr 03, 2019 at 10:01:03AM -0600, Anthony J. Bentley wrote:
> Diogo Galvao writes:
> > On Thu, Nov 1, 2018 at 10:15 PM Diogo Galvao  wrote:
> > > So the condition ((wsenc & kbdvar[i].val) == kbdvar[i].val) ends up
> > > being true for KB_BR & KB_SF, therefore "fr" variant gets configured.
> > > That bitmasking was introduced in revision 1.15 along with a bitmask for
> > > choosing keyboard options:
> > >
> > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/xserver/config/wscons.c#
> > rev1.15
> > >
> > > I used this small patch to get back part of the old behavior:
> 
> Thanks for the bug report (and the reminder).
> 
> The code is indeed broken in the way you describe. However, you're also
> correct that reverting it would re-break the case where multiple options
> are set, like us.dvorak.swapctrlcaps.
> 
> I came up with the following diff. Please give it a try.
> 
> In my tests, the following kbd(8) settings are no longer marked "using
> variant fr":
> 
> ua
> pt
> pt.apple
> lt
> la
> br
> tr
> pl
> si
> lv
> nl
> is
> ee
> 
> tr.nodead, nl.nodead, is.nodead, and ee.nodead become "variant nodeadkeys"
> instead of "variant fr_nodeadkeys".

That all looks good.
> 
> cf becomes "variant fr-legacy" instead of "variant fr".
> 
> cf.nodead becomes "variant fr-legacy" instead of "variant
> fr_nodeadkeys".

I don't know the subtilities of the canadian french keyboards, but
that looks as a a behaviour change (even though it's more correct). Is
it ok for canadian french keyboard users?

Otherwise your patch looks ok to me. ok matthieu@

> 
> The remainder of the 54 keyboards listed by kbd -l for pc-xt/pc-at and
> usb are unchanged.
> 
> All this seems like the result we want.
> 
> ok?
> 
> 
> Index: xserver/config/wscons.c
> ===
> RCS file: /cvs/xenocara/xserver/config/wscons.c,v
> retrieving revision 1.22
> diff -u -p -r1.22 wscons.c
> --- xserver/config/wscons.c   30 Jul 2018 16:00:39 -  1.22
> +++ xserver/config/wscons.c   3 Apr 2019 15:50:16 -
> @@ -139,7 +139,9 @@ wscons_add_keyboard(void)
>  break;
>  }
>  for (i = 0; kbdvar[i].val; i++)
> -if ((wsenc & kbdvar[i].val) == kbdvar[i].val) {
> +if ((wsenc & kbdvar[i].val) == kbdvar[i].val &&
> +(KB_ENCODING(wsenc) == KB_ENCODING(kbdvar[i].val) ||
> +!KB_ENCODING(kbdvar[i].val))) {
>  LogMessageVerb(X_INFO, 3, "wskbd: using variant %s\n",
> kbdvar[i].name);
>  input_options = input_option_new(input_options,

-- 
Matthieu Herrb

Re: xenodm starts with only cursor showing

[Matthieu Herrb]

On Sat, Mar 23, 2019 at 04:59:32PM -0500, Lucas Raab wrote:
> >Synopsis:xenodm starts with only cursor shown, but windows are "hidden"
> >Category:system
> >Environment:
>   System  : OpenBSD 6.5
>   Details : OpenBSD 6.5-beta (GENERIC.MP) #820: Fri Mar 22 12:43:30 
> MDT 2019
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   xenodm will start successfully, but only show the cursor. The login 
> fields are not shown, but it is possible to log in by typing the username and 
> tabbing to the password field. From here, I can start applications yet cannot 
> see them. Inconsistently, I will see X running at 100% as the _x11 user.
> 
>   I believe this started with Tuesday's (2018-03-19) snapshot. Checking out 
> the recent commits, I saw the xorg-server and Mesa version bumps so I am 
> wondering if there's a correlation there with my Intel hardware (Intel 630).
> 
> Lucas
> >How-To-Repeat:
>   Reboot or restart xenodm
> >Fix:
>   unknown

Hi,

Thanks for the report. can you check the contents of
/var/log/xenodm.log and send it here if there are any visible error
messages ?

-- 
Matthieu Herrb

Re: X segmentation fault by chromium

[Matthieu Herrb]

On Mon, Mar 04, 2019 at 09:14:45AM +0100, Matthieu Herrb wrote:
> On Sat, Mar 02, 2019 at 10:24:22PM +0200, Mihai Popescu wrote:
> > Hello,
> > 
> > I am able to generate a segmentation fault on X with chromium help.
> > This is happening each time I visit the web page at [1]. Basically,
> > there is a picture of a product and whenever I hover the mouse over
> > it, X gets a segmentation fault and exits at xenodm login prompt.
> > Sometimes, if I repeat this procedure over and over, I get an offset
> > for the image on my display, making things hard to see.
> > 
> > [1] 
> > https://computers.woot.com/offers/lenovo-thinkcentre-m78-amd-a4-sff-desktop-1
> > 
> > I have inspected the web page in question with firefox, and I can tell
> > the page loads a special image cursor when I hover on the picture in
> > question. No segmentation fault for X this time.
> > 
> 
> Hi,
> 
> Thanks for the bug report. Can you try the attached patch (from
> upstream) ?

Maybe I was too terse. To test this patch :

cd /usr/xenocara/driver/xf86-video-ati
patch < /path/to/the/patch
doas make -f Makefile.bsd-wrapper obj
doas make -f Makefile.bsd-wrapper build

and restart the X server before opening the web page in chrome.
-- 
Matthieu Herrb

Re: X segmentation fault by chromium

[Matthieu Herrb]

 
drmmode_cursor_src_offset(crtc->rotation,
  cursor_w,
  cursor_h,
  dstx, 
dsty);
+   argb = image[srcoffset];
+   if (!drmmode_cursor_pixel(crtc, , 
,
+ _gamma))
+   goto retry_transform;
 
-   ptr[dsty * info->cursor_w + dstx] =
-   cpu_to_le32(drmmode_cursor_gamma(crtc,
-
image[srcoffset]));
+   ptr[dsty * info->cursor_w + dstx] = 
cpu_to_le32(argb);
}
}
} else
@@ -1098,8 +1140,15 @@ drmmode_load_cursor_argb (xf86CrtcPtr cr
uint32_t cursor_size = info->cursor_w * info->cursor_h;
int i;
 
-   for (i = 0; i < cursor_size; i++)
-   ptr[i] = cpu_to_le32(drmmode_cursor_gamma(crtc, 
image[i]));
+retry:
+   for (i = 0; i < cursor_size; i++) {
+   argb = image[i];
+   if (!drmmode_cursor_pixel(crtc, , ,
+ _gamma))
+   goto retry;
+
+   ptr[i] = cpu_to_le32(argb);
+   }
}
 }
 

-- 
Matthieu Herrb

Re: Xorg crash on Intel HD Graphics 620 inside intel_drv.so

[Matthieu Herrb]

On Mon, Feb 04, 2019 at 07:08:25PM +, Mikolaj Kucharski wrote:
> Hi,
> 
> Sorry for missing subject line in my initial report. I tested git
> checkout of commit c37c7ee0748ba828ec5d2c7304cd2a17af2c8109 of
> xf86-video-intel driver from:
> 
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel.git
> 
> and it seems to work for me on Huawei MateBook X and the crash reported
> below is gone.
> 
> From what I can see, there are rare releases of xf86-video-intel driver,
> so would be possible to import to Xenocara git snapshot of the driver, if
> there is no recent code release?

Last time I tried there were a number of regression on some older
hardware. If you can identify which commit is fixing the crash, I
would be happy to check if it can be back-ported.

The state of the xf86-video-intel driver is sad. But everyone is
moving away from it to the modesettings driver. Hopefully the current
work on upgrading the kernel-side DRM code and the upcoming upgrade to
xserver 1,20.x will also improve the modesetting driver on OpenBSD, so
that less people will need to run the intel driver.

-- 
Matthieu Herrb

Re: Xorg always crashes after tty switch

[Matthieu Herrb]

On Mon, Dec 17, 2018 at 02:19:02PM +, autos...@riseup.net wrote:
> 
> I have had this occur on both FreeBSD and OpenBSD, with slightly different
> Intel Atom processors.
> 
> Switching TTY is generally problem-free.
> Once Xorg is running on a TTY, switching away from that TTY to a console TTY
> causes no problems.
> However, switching from console TTY to an Xorg TTY causes the entire system to
> crash, with a crazy glitch-looking mix of colours on the screen, sometimes 
> pink,
> sometimes blue, etc.
> 
> Note this doesn't happen when starting Xorg, either.
> So the only way to switch from console TTY back to Xorg TTY without crashing, 
> is
> to run:
> rcctl stop xenodm
> rcctl -f start xenodm
> 
> When I have checked in the past there have been no indicating logs in Xorg,
> probably because of the crash. There is no response to keyboard/mouse input 
> once
> it has crashed, so nothing more can be done other than a hard reset.
> 
> I can only think using a serial port might offer a route for diagnostics.
> 
> Any suggestions? I could live with bug, but it is time-wasting nuisance.

Hi,

start by sending a proper bug report, ie. include dmesg,
/var/log/Xorg.0.log outputs,...
See https://www.openbsd.org/report.html for details.

Next /usr/xenocara/README[1] has some hints on how to get
a core file out of the X server. Please try to get one an
extract a stack trace using gdb from ports.

[1] 
https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/README?rev=1.42=text/plain
-- 
Matthieu Herrb

Re: X.org -current with xenodm segmentation fault (xlock?)

[Matthieu Herrb]

Module: "ws"
> [1015429.441] (II) Loading /usr/X11R6/lib/modules/input/ws_drv.so
> [1015429.441] (II) Module ws: vendor="X.Org Foundation"
> [1015429.441] compiled for 1.19.6, module version = 1.3.0
> [1015429.441] Module class: X.Org XInput Driver
> [1015429.441] ABI class: X.Org XInput driver, version 24.1
> [1015429.441] (II) Using input driver 'ws' for '/dev/wsmouse'
> [1015429.441] (**) /dev/wsmouse: always reports core events
> [1015429.441] (II) ws: /dev/wsmouse: debuglevel 0
> [1015429.441] (**) Option "Device" "/dev/wsmouse"
> [1015429.441] (**) ws: /dev/wsmouse: ZAxisMapping: buttons 4 and 5
> [1015429.441] (**) ws: /dev/wsmouse: WAxisMapping: buttons 6 and 7
> [1015429.441] (**) ws: /dev/wsmouse: associated screen: 0
> [1015429.441] (II) ws: /dev/wsmouse: minimum x position: 0
> [1015429.441] (II) ws: /dev/wsmouse: maximum x position: 1919
> [1015429.441] (II) ws: /dev/wsmouse: minimum y position: 0
> [1015429.441] (II) ws: /dev/wsmouse: maximum y position: 1199
> [1015429.441] (==) ws: /dev/wsmouse: Buttons: 7
> [1015429.442] (**) ws: /dev/wsmouse: YAxisMapping: buttons 4 and 5
> [1015429.442] (II) XINPUT: Adding extended input device "/dev/wsmouse"
> (type: MOUSE, id 7)
> [1015429.442] (**) /dev/wsmouse: (accel) keeping acceleration scheme 1
> [1015429.442] (**) /dev/wsmouse: (accel) acceleration profile 0
> [1015429.442] (**) /dev/wsmouse: (accel) acceleration factor: 2.000
> [1015429.442] (**) /dev/wsmouse: (accel) acceleration threshold: 4
> [1015482.469] (II) AIGLX: Suspending AIGLX clients for VT switch
> [1015485.379] (II) AIGLX: Resuming AIGLX clients after VT switch
> [1015485.423] (II) RADEON(0): EDID vendor "HWP", prod id 9976
> [1015485.423] (II) RADEON(0): Using EDID range info for horizontal sync
> [1015485.423] (II) RADEON(0): Using EDID range info for vertical refresh
> [1015485.423] (II) RADEON(0): Printing DDC gathered Modelines:
> [1015485.423] (II) RADEON(0): Modeline "1920x1200"x0.0  154.00  1920
> 1968 2000 2080  1200 1203 1209 1235 +hsync -vsync (74.0 kHz eP)
> [1015485.423] (II) RADEON(0): Modeline "1920x1080i"x0.0   74.25  1920
> 2008 2052 2200  1080 1084 1094 1125 interlace +hsync +vsync (33.8 kHz e)
> [1015485.423] (II) RADEON(0): Modeline "1920x1080i"x0.0   74.25  1920
> 2448 2492 2640  1080 1084 1094 1125 interlace +hsync +vsync (28.1 kHz e)
> [1015485.423] (II) RADEON(0): Modeline "1280x720"x0.0   74.25  1280 1390
> 1430 1650  720 725 730 750 +hsync +vsync (45.0 kHz e)
> [1015485.423] (II) RADEON(0): Modeline "1280x720"x0.0   74.25  1280 1720
> 1760 1980  720 725 730 750 +hsync +vsync (37.5 kHz e)
> [1015485.423] (II) RADEON(0): Modeline "800x600"x0.0   40.00  800 840
> 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
> [1015485.423] (II) RADEON(0): Modeline "640x480"x0.0   31.50  640 656
> 720 840  480 481 484 500 -hsync -vsync (37.5 kHz e)
> [1015485.423] (II) RADEON(0): Modeline "640x480"x0.0   25.18  640 656
> 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
> [1015485.423] (II) RADEON(0): Modeline "720x400"x0.0   28.32  720 738
> 846 900  400 412 414 449 -hsync +vsync (31.5 kHz e)
> [1015485.423] (II) RADEON(0): Modeline "1280x1024"x0.0  135.00  1280
> 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
> [1015485.423] (II) RADEON(0): Modeline "1024x768"x0.0   78.75  1024 1040
> 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
> [1015485.423] (II) RADEON(0): Modeline "1024x768"x0.0   65.00  1024 1048
> 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
> [1015485.423] (II) RADEON(0): Modeline "832x624"x0.0   57.28  832 864
> 928 1152  624 625 628 667 -hsync -vsync (49.7 kHz e)
> [1015485.423] (II) RADEON(0): Modeline "800x600"x0.0   49.50  800 816
> 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz e)
> [1015485.423] (II) RADEON(0): Modeline "1152x864"x0.0  108.00  1152 1216
> 1344 1600  864 865 868 900 +hsync +vsync (67.5 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1280x960"x0.0  108.00  1280 1376
> 1488 1800  960 961 964 1000 +hsync +vsync (60.0 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1280x1024"x0.0  108.00  1280
> 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1600x1000"x60.0  133.14  1600
> 1704 1872 2144  1000 1001 1004 1035 -hsync +vsync (62.1 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1600x1200"x0.0  162.00  1600
> 1664 1856 2160  1200 1201 1204 1250 +hsync +vsync (75.0 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1680x1050"x0.0  119.00  1680
> 1728 1760 1840  1050 1053 1059 1080 +hsync -vsync (64.7 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1920x1080"x60.0  172.80  1920
> 2040 2248 2576  1080 1081 1084 1118 -hsync +vsync (67.1 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "720x480"x0.0   27.00  720 736
> 798 858  480 489 495 525 -hsync -vsync (31.5 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1440x480i"x0.0   27.00  1440
> 1478 1602 1716  480 488 494 525 interlace -hsync -vsync (15.7 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1920x1080"x0.0  148.50  1920
> 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "720x576"x0.0   27.00  720 732
> 796 864  576 581 586 625 -hsync -vsync (31.2 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1440x576i"x0.0   27.00  1440
> 1464 1590 1728  576 580 586 625 interlace -hsync -vsync (15.6 kHz e)
> [1015485.424] (II) RADEON(0): Modeline "1920x1080"x0.0  148.50  1920
> 2448 2492 2640  1080 1084 1089 1125 +hsync +vsync (56.2 kHz e)
> [1050507.209] (EE) Segmentation fault at address 0xaae4da74000
> [1050507.216] (EE)
> Fatal server error:
> [1050507.216] (EE) Caught signal 11 (Segmentation fault). Server aborting
> [1050507.216] (EE)
> [1050507.216] (EE)
> Please consult the The X.Org Foundation support
>at http://wiki.x.org
>  for help.
> [1050507.216] (EE) Please also check the log file at
> "/var/log/Xorg.0.log" for additional information.
> [1050507.216] (EE)
> [1050507.218] (EE) ws: /dev/wsmouse: unknown command 4
> [1050507.218] (II) AIGLX: Suspending AIGLX clients for VT switch
> [1050507.664] (EE) Server terminated with error (1). Closing log file.

-- 
Matthieu Herrb

Re: /usr/local/bin/mosh broken by recent ssh changes ?

[Matthieu Herrb]

On Sun, Nov 18, 2018 at 10:10:30AM +1100, Darren Tucker wrote:
> On Sun, Nov 18, 2018 at 10:03:20AM +1100, Darren Tucker wrote:
> > On Sun, 18 Nov 2018 at 09:48, Darren Tucker  wrote:
> > 
> > > Was able to reproduce and confirmed by bisecting that the "redirect stderr
> > > of ProxyCommands to /dev/null when ssh is started with ControlPersist"
> > > change is where it breaks, but I don't understand what mosh is doing under
> > > the covers that now doesn't work.  Will look further.
> > >
> > 
> > Not sure if I understand the intent of the change correctly, but to me the
> > logic looks inverted.
> > 
> > /*
> >  * Stderr is left for non-ControlPersist connections is so
> >  * error messages may be printed on the user's terminal.
> >  */
> > if (debug_flag || !options.control_persist)
> > stderr_null();
> > 
> > If nothing else the control_persist part should probably check if
> > ControlPath is set too.
> 
> ok?

This fixes the issue for me yes.
Thanks.

> 
> diff --git a/sshconnect.c b/sshconnect.c
> index a700f467..ed86d0d9 100644
> --- a/sshconnect.c
> +++ b/sshconnect.c
> @@ -163,7 +163,8 @@ ssh_proxy_fdpass_connect(struct ssh *ssh, const char 
> *host, u_short port,
>* Stderr is left for non-ControlPersist connections is so
>* error messages may be printed on the user's terminal.
>*/
> - if (debug_flag || !options.control_persist)
> + if (!debug_flag && options.control_path != NULL &&
> + options.control_persist)
>   stderr_null();
>  
>   argv[0] = shell;
> @@ -245,7 +246,8 @@ ssh_proxy_connect(struct ssh *ssh, const char *host, 
> u_short port,
>* Stderr is left for non-ControlPersist connections is so
>* error messages may be printed on the user's terminal.
>*/
> - if (debug_flag || !options.control_persist)
> + if (!debug_flag && options.control_path != NULL &&
> + options.control_persist)
>   stderr_null();
>  
>   argv[0] = shell;
> 
> -- 
> Darren Tucker (dtucker at dtucker.net)
> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
> Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.

-- 
Matthieu Herrb

Re: /usr/local/bin/mosh broken by recent ssh changes ?

[Matthieu Herrb]

On Sat, Nov 17, 2018 at 09:47:19PM +1100, Darren Tucker wrote:
> On Sat, 17 Nov 2018 at 18:29, Matthieu Herrb  wrote:
> 
> > on amd64-current on the client side, mosh now fails to connect to
> > remote hosts :
> >
> > /usr/local/bin/mosh: Did not find remote IP address (is SSH ProxyCommand
> > disabled?).
> > Exit 10
> >
> 
> What does the client's ~/.ssh/config look like for that host?
>

Nothing special. only host * at the end with
ForwardAgent no
ForwardX11 no


that's probably redundant.


> -- 
> Darren Tucker (dtucker at dtucker.net)
> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
> Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.

-- 
Matthieu Herrb

/usr/local/bin/mosh broken by recent ssh changes ?

[Matthieu Herrb]

Hi,

on amd64-current on the client side, mosh now fails to connect to
remote hosts : 

/usr/local/bin/mosh: Did not find remote IP address (is SSH ProxyCommand 
disabled?).
Exit 10

The remote host has not changed its configuration (It's an OpenBSD 6.2
machine that I haven't upgraded or rebooted yet).

Apparently there where changes in the way ProxyCommand is handled in
ssh, but it doesn't look like it's now disabled by default.

Did I miss something?

 > From: Damien Miller 
 > Date: Thu, 15 Nov 2018 23:17:38 -0700 (MST)
 > To: source-chan...@openbsd.org
 > Subject: CVS: cvs.openbsd.org: src
 > 
 > CVSROOT:/cvs
 > Module name:src
 > Changes by: d...@cvs.openbsd.org 2018/11/15 23:17:38
 > 
 > Modified files:
 > usr.bin/ssh: sshconnect.c
 > 
 > Log message:
 > redirect stderr of ProxyCommands to /dev/null when ssh is started with
 > ControlPersist; based on patch from Steffen Prohaska

-- 
Matthieu Herrb
 

Re: l2k18 ahoy [s_g...@telus.net: FW: SSL connection failure with ftp but not wget [...]

[Matthieu Herrb]

On Mon, Nov 05, 2018 at 10:03:31PM +0100, Mark Kettenis wrote:
> > Date: Mon, 5 Nov 2018 20:56:33 +
> > From: Stuart Henderson 
> > 
> > Probably worth pinging this one since l2k18 is on.
> > 
> > s_graf is trying to fetch ports sources from https://pypi.org/ and is
> > getting a hang and eventually a timeout when attempting connection from
> > ftp(1) on armv7. (From recent ports@ posts it seems like this still occurs).
> > 
> > curl/wget were working ok when tested before.
> > 
> > Can anyone with armv7 confirm/deny that they can replicate this? (just try
> > "ftp https://pypi.io/packages/source/s/six/six-1.11.0.tar.gz;).
> > 
> > Any ideas?
> 
> Works for me with an install built from source last update Oct 29th
> or so.

Works for me too on a -current built here this weekend.
Note that there is IPv6 involved. So IPv6 routing issues (IPMPv6
filtering causing MTU negociation failures) can interfere...

sabre% ftp https://pypi.iœpackages/source/s/six/six-1.11.0.tar.gz
Trying 2a04:4e42:400::223...
Requesting https://pypi.iœpackages/source/s/six/six-1.11.0.tar.gz
Redirected to https://pypi.org/packages/source/s/six/six-1.11.0.tar.gz
Trying 2a04:4e42:400::223...
Requesting https://pypi.org/packages/source/s/six/six-1.11.0.tar.gz
Redirected to
https://files.pythonhosted.org/packages/source/s/six/six-1.11.0.tar.gz
Trying 2a04:4e42:1d::319...
Requesting
https://files.pythonhosted.org/packages/source/s/six/six-1.11.0.tar.gz
Redirected to
https://files.pythonhosted.org/packages/16/d8/bc6316cf98419719bd59c91742194c111b6f2e85abac88e496adefaf7afe/six-1.11.0.tar.gz
Trying 2a04:4e42:1d::319...
Requesting
https://files.pythonhosted.org/packages/16/d8/bc6316cf98419719bd59c91742194c111b6f2e85abac88e496adefaf7afe/six-1.11.0.tar.gz
100%
|*****|
29860   00:00
29860 bytes received in 0.07 seconds (412.27 KB/s)

-- 
Matthieu Herrb

Re: xenodm login screen

[Matthieu Herrb]

On Sun, Oct 28, 2018 at 06:45:16PM +0100, Klemens Nanni wrote:
> On Sun, Oct 28, 2018 at 06:19:11PM +0100, Matthieu Herrb wrote:
> > -strlcpy(prompt, message, messageLen);
> > +strlcpy(prompt, message, messageLen+3);
> So this turns "logi" into "login: "?

Yes.
> 
> Not a big deal, but these `messageLen +- MAGIC_OFFSET' seem somewhat
> hackish.
> 
> Can you add spaces so it's consistent with the rest at least?

Sure this is terrible. It's still from xdm. I wanted to clean that up
in LJU last july but didn't find the time.

The whole way the login widget layout is computed is hackish and not
very robust. It needs to be redone at some point.

-- 
Matthieu Herrb

Re: xenodm login screen

[Matthieu Herrb]

On Sun, Oct 28, 2018 at 08:42:55AM -0500, Edgar Pettijohn III wrote:
> >Synopsis: xenodm truncates xlogin.Login.namePrompt and
> xlogin.Login.passwdPrompt
> >Category: user
> >Environment:
>     System  : OpenBSD 6.4
>     Details : OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT
> 2018
>  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>     Architecture: OpenBSD.amd64
>     Machine : amd64
> >Description:
>     I have the following in /etc/X11/xenodm/Xresources:
> 
>     xlogin.Login.namePrompt:    login
>     xlogin.Login.passwdPrompt:    passwd
> 
>     However, when the login screen pops up it shows the following:
> 
>     logi
>     passw

Hi,

the patch below should fix it:

Index: app/xenodm/greeter/Login.c
===
RCS file: /cvs/OpenBSD/xenocara/app/xenodm/greeter/Login.c,v
retrieving revision 1.4
diff -u -p -u -r1.4 Login.c
--- app/xenodm/greeter/Login.c  11 Jul 2018 16:28:54 -  1.4
+++ app/xenodm/greeter/Login.c  28 Oct 2018 17:18:23 -
@@ -754,7 +754,7 @@ SetPrompt (Widget ctx, int promptNum, co
 return -1;
 }
 
-strlcpy(prompt, message, messageLen);
+strlcpy(prompt, message, messageLen+3);
 
 /* Make sure text prompts have at least two spaces at end */
 e = messageLen;

-- 
Matthieu Herrb

Re: [PATCH] incorrect path in ssh-askpass(1)

[Matthieu Herrb]

On Sat, Oct 27, 2018 at 12:31:21PM +0200, Sascha Paunovic wrote:
> > Synopsis: the manpage ssh-askpass(1) references a non-existent file
> > Category: documentation
> > Environment:
> System  : OpenBSD 6.4
> Details : OpenBSD 6.4-current (GENERIC.MP) #393: Fri Oct 26 09:16:42
> MDT 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> Architecture: OpenBSD.amd64
> Machine : amd64
> > Description:
> The manpage ssh-askpass(1), in the section FILES references to
> "/etc/X11/app-defaults/SshAskpass" which doesn't exist and should be
> "/usr/X11R6/share/X11/app-defaults/SshAskpass" instead.
> > How-To-Repeat:
> man 1 ssh-askpass
> > Fix:
> Diff attached to this message.

Hi,

Thanks for your report.

Stricly speaking, the application resources are searched following the
XFILESEARCHPATH variable described in the X(7) manual page.

Some commonly established usage is to let systems install the default
value in /usr, and let system administrator put locally modified
versions in /etc, and eventually have users put their own version in
${HOME}.

So I would rather use the patch below, that also replaces another
occurence of /etc/X11.

Index: x11-ssh-askpass.man.in
===
RCS file: /cvs/OpenBSD/xenocara/app/ssh-askpass/x11-ssh-askpass.man.in,v
retrieving revision 1.5
diff -u -r1.5 x11-ssh-askpass.man.in
--- x11-ssh-askpass.man.in  8 Apr 2011 20:03:47 -   1.5
+++ x11-ssh-askpass.man.in  27 Oct 2018 16:12:15 -
@@ -45,7 +45,7 @@
 .Bl -dash -offset indent
 .It 
 Configurable via the standard X resource mechanisms
-.Pa /etc/X11/app-defaults ,
+.Pa /usr/X11R6/share/X11/app-defaults ,
 .Pa ~/.Xdefaults ,
 .Xr xrdb 1 ,
 etc.
@@ -285,8 +285,9 @@
 the font to use for this button label.
 .El
 .Sh FILES
-.Bl -tag -width "/etc/X11/app-defaults/SshAskpass" -compact
-.It Pa /etc/X11/app-defaults/SshAskpass
+.Bl -tag -width Ds -compact
+.It Pa /usr/X11R6/share/X11/app-defaults/SshAskpass
+The default application resources.
 .El
 .Sh SEE ALSO
 .Xr ssh 1 ,

-- 
Matthieu Herrb

Re: X segfaults (reproducible, I think)

[Matthieu Herrb]

On Wed, Oct 17, 2018 at 10:51:00AM +0300, Gregory Edigarov wrote:
> 
> On 16.10.18 13:18, Matthieu Herrb wrote:
> >On Tue, Oct 16, 2018 at 10:59:19AM +0100, Stuart Henderson wrote:
> >>On 2018/10/16 12:17, Gregory Edigarov wrote:
> >>>if somebody tell me how to get a core from X server, i will also
> >>provide it.
> >Hi,
> >
> >If possible, try to run gdb to get a backtrace and post the
> >backtrace. It will be more efficient.
> >
> >Also, are you forcing X to use the intel driver via an xorg.conf file?
> 
> Yes, i am enforcing, because I also have radeon in this box, and if i am not
> enforcing, X chooses radeon on which I have no monitors right now.

Looks like an issue in the intel driver...

Can you try  enforcing the modesetting driver instead ?

You may need to set Option "kmsdev" "/dev/drm0" to make sure it uses
inteldrm and not radeondrm. (or disable radeondrm in 'boot -c').

The situation about the intel driver is sad. It has not seen a formal
release for years now, the code in git master is broken with
not-so-old devices (and probably needs features not present in
OpenBSD's drm version). So modesetting is currently the way to go.
There are issues too, but there is more chance to see them fixed as we
catch up with drm and Mesa.

> 
> the backtrace:
> 
> GNU gdb 6.3
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-unknown-openbsd6.4"...
> Core was generated by `Xorg'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/lib/libpthread.so.25.1...done.
> Loaded symbols for /usr/lib/libpthread.so.25.1
> Loaded symbols for /usr/X11R6/bin/Xorg
> Symbols already loaded for /usr/lib/libpthread.so.25.1
> Reading symbols from /usr/X11R6/lib/libpciaccess.so.2.0...done.
> Loaded symbols for /usr/X11R6/lib/libpciaccess.so.2.0
> Reading symbols from /usr/X11R6/lib/libdrm.so.7.6...done.
> Loaded symbols for /usr/X11R6/lib/libdrm.so.7.6
> Reading symbols from /usr/X11R6/lib/libpixman-1.so.32.6...done.
> Loaded symbols for /usr/X11R6/lib/libpixman-1.so.32.6
> Reading symbols from /usr/X11R6/lib/libXfont2.so.1.0...done.
> Loaded symbols for /usr/X11R6/lib/libXfont2.so.1.0
> Reading symbols from /usr/X11R6/lib/libfontenc.so.4.0...done.
> Loaded symbols for /usr/X11R6/lib/libfontenc.so.4.0
> Reading symbols from /usr/X11R6/lib/libfreetype.so.29.0...done.
> Loaded symbols for /usr/X11R6/lib/libfreetype.so.29.0
> Reading symbols from /usr/lib/libz.so.5.0...done.
> Loaded symbols for /usr/lib/libz.so.5.0
> Reading symbols from /usr/X11R6/lib/libXau.so.10.0...done.
> Loaded symbols for /usr/X11R6/lib/libXau.so.10.0
> Reading symbols from /usr/X11R6/lib/libxshmfence.so.0.0...done.
> Loaded symbols for /usr/X11R6/lib/libxshmfence.so.0.0
> Reading symbols from /usr/X11R6/lib/libXdmcp.so.11.0...done.
> Loaded symbols for /usr/X11R6/lib/libXdmcp.so.11.0
> Reading symbols from /usr/lib/libkvm.so.17.0...done.
> Loaded symbols for /usr/lib/libkvm.so.17.0
> Reading symbols from /usr/lib/libm.so.10.1...done.
> Loaded symbols for /usr/lib/libm.so.10.1
> Reading symbols from /usr/lib/libc.so.92.5...done.
> Loaded symbols for /usr/lib/libc.so.92.5
> Reading symbols from /usr/libexec/ld.so...done.
> Loaded symbols for /usr/libexec/ld.so
> Reading symbols from /usr/X11R6/lib/modules/extensions/libglx.so...done.
> Loaded symbols for /usr/X11R6/lib/modules/extensions/libglx.so
> Reading symbols from /usr/X11R6/lib/libGL.so.17.1...done.
> Loaded symbols for /usr/X11R6/lib/libGL.so.17.1
> Reading symbols from /usr/lib/libexpat.so.12.0...done.
> Loaded symbols for /usr/lib/libexpat.so.12.0
> Reading symbols from /usr/X11R6/lib/libxcb-dri3.so.0.1...done.
> Loaded symbols for /usr/X11R6/lib/libxcb-dri3.so.0.1
> Reading symbols from /usr/X11R6/lib/libxcb-present.so.0.1...done.
> Loaded symbols for /usr/X11R6/lib/libxcb-present.so.0.1
> Reading symbols from /usr/X11R6/lib/libxcb-sync.so.1.2...done.
> Loaded symbols for /usr/X11R6/lib/libxcb-sync.so.1.2
> Reading symbols from /usr/X11R6/lib/libglapi.so.0.2...done.
> Loaded symbols for /usr/X11R6/lib/libglapi.so.0.2
> Reading symbols from /usr/X11R6/lib/libXdamage.so.4.0...done.
> Loaded symbols for /usr/X11R6/lib/libXdamage.so.4.0
> Reading symbols from /usr/X11R6/lib/libXfixes.so.6.0...done.
> Loaded symbols for /usr/X11R6/lib/libXfixes.so.6.0
> Reading symbols from /usr/X11R6/lib/libX11-xcb.so.2.0...done.
> Loaded symbol

Re: X segfaults (reproducible, I think)

[Matthieu Herrb]

On Tue, Oct 16, 2018 at 10:59:19AM +0100, Stuart Henderson wrote:
> On 2018/10/16 12:17, Gregory Edigarov wrote:
> > if somebody tell me how to get a core from X server, i will also
> provide it.

Hi,

If possible, try to run gdb to get a backtrace and post the
backtrace. It will be more efficient.

Also, are you forcing X to use the intel driver via an xorg.conf file?

-- 
Matthieu Herrb

panic: fork: encountered a submap during fork (illegal)

[Matthieu Herrb]

ntel 200 Series PCIE" rev 0xf0: msi
pci8 at ppb7 bus 8
ppb8 at pci0 dev 29 function 2 "Intel 200 Series PCIE" rev 0xf0: msi
pci9 at ppb8 bus 9
ppb9 at pci0 dev 29 function 3 "Intel 200 Series PCIE" rev 0xf0: msi
pci10 at ppb9 bus 10
pcib0 at pci0 dev 31 function 0 "Intel B250 LPC" rev 0x00
"Intel 200 Series PMC" rev 0x00 at pci0 dev 31 function 2 not configured
azalia0 at pci0 dev 31 function 3 "Intel 200 Series HD Audio" rev 0x00: msi
azalia0: codecs: Realtek/0x0887, Intel/0x280b, using Realtek/0x0887
audio0 at azalia0
ichiic0 at pci0 dev 31 function 4 "Intel 200 Series SMBus" rev 0x00: apic 2 int 
16
iic0 at ichiic0
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
lpt0 at isa0 port 0x378/4 irq 7
vmm0 at mainbus0: VMX/EPT (using slow L1TF mitigation)
efifb at mainbus0 not configured
uhidev0 at uhub0 port 3 configuration 1 interface 0 "Cypress Sem Cypress USB 
Mouse" rev 1.00/4.9c addr 2
uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons, Z dir
wsmouse0 at ums0 mux 0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (d0243d0b9c113a2f.a) swap on sd0b dump on sd0b

-- 
Matthieu Herrb

Re: fcntl(2) manpage is wrong about F_GETFD return value

[Matthieu Herrb]

On Mon, Aug 06, 2018 at 06:32:01PM +0200, Claudio Jeker wrote:
> On Mon, Aug 06, 2018 at 06:23:28PM +0200, Matthieu Herrb wrote:
> > Hi,
> > 
> > fcntl(2) says:
> > 
> >  F_GETFD  Get the close-on-exec flag associated with the file
> >   descriptor fd as FD_CLOEXEC.  If the returned value
> >   ANDed with FD_CLOEXEC is 0, the file will remain open
> >   across exec(), otherwise the file will be closed upon
> >   execution of exec() (arg is ignored).
> > 
> > This is wrong. The flag is returned in the low bit of the return
> > value (see sys/kern/kern_descrip.c:443).
> > Moreover the value O_CLOEXEC is not 0x1, so doing the AND described
> > above is never going to provide the good answer.
> > 
> > I've checked that Linux and FreeBSD also return 0x1 when the O_CLOEXEC
> > is set, and none of them defines O_CLOEXEC as 0x1. The same
> > documentation bug is present on FreenBSD.
> > 
> > How to repeat:
> > 
> > #include 
> > #include 
> > #include 
> > 
> > int
> > main(int argc, char *argv[])
> > {
> > int fd, flags;
> > 
> > fd = open("/dev/null", O_RDWR | O_CLOEXEC);
> > if (fd < 0)
> > err(2, "open");
> > flags = fcntl(fd, F_GETFD, 0);
> > if (flags < 0)
> > err(2, "fcntl");
> > printf("flags 0x%08x O_CLOEXEC 0x%08x\n", flags, O_CLOEXEC);
> > return 0;
> > }
> 
> There is a difference between FD_CLOEXEC and O_CLOEXEC. FD_CLOEXEC is
> defined as 1 and so the man page is correct.

Ok. This is confusing but you're correct. sigh.
> 
>  
> > Patch
> > 
> > The patch below fixes the documentation.
> > 
> > Index: fcntl.2
> > ===
> > RCS file: /cvs/OpenBSD/src/lib/libc/sys/fcntl.2,v
> > retrieving revision 1.31
> > diff -u -p -u -r1.31 fcntl.2
> > --- fcntl.2 16 Dec 2014 00:06:49 -  1.31
> > +++ fcntl.2 6 Aug 2018 16:10:53 -
> > @@ -100,10 +100,7 @@ Get the close-on-exec flag associated wi
> >  .Fa fd
> >  as
> >  .Dv FD_CLOEXEC .
> > -If the returned value ANDed with
> > -.Dv FD_CLOEXEC
> > -is 0,
> > -the file will remain open across
> > +If the returned value is 0, the file will remain open across
> >  .Fn exec ,
> >  otherwise the file will be closed upon execution of
> >  .Fn exec
> > 
> > 
> 
> 
> -- 
> :wq Claudio

-- 
Matthieu Herrb

fcntl(2) manpage is wrong about F_GETFD return value

[Matthieu Herrb]

Hi,

fcntl(2) says:

 F_GETFD  Get the close-on-exec flag associated with the file
  descriptor fd as FD_CLOEXEC.  If the returned value
  ANDed with FD_CLOEXEC is 0, the file will remain open
  across exec(), otherwise the file will be closed upon
  execution of exec() (arg is ignored).

This is wrong. The flag is returned in the low bit of the return
value (see sys/kern/kern_descrip.c:443).
Moreover the value O_CLOEXEC is not 0x1, so doing the AND described
above is never going to provide the good answer.

I've checked that Linux and FreeBSD also return 0x1 when the O_CLOEXEC
is set, and none of them defines O_CLOEXEC as 0x1. The same
documentation bug is present on FreenBSD.

How to repeat:

#include 
#include 
#include 

int
main(int argc, char *argv[])
{
int fd, flags;

fd = open("/dev/null", O_RDWR | O_CLOEXEC);
if (fd < 0)
err(2, "open");
flags = fcntl(fd, F_GETFD, 0);
if (flags < 0)
err(2, "fcntl");
printf("flags 0x%08x O_CLOEXEC 0x%08x\n", flags, O_CLOEXEC);
return 0;
}

Patch

The patch below fixes the documentation.

Index: fcntl.2
===
RCS file: /cvs/OpenBSD/src/lib/libc/sys/fcntl.2,v
retrieving revision 1.31
diff -u -p -u -r1.31 fcntl.2
--- fcntl.2 16 Dec 2014 00:06:49 -  1.31
+++ fcntl.2 6 Aug 2018 16:10:53 -
@@ -100,10 +100,7 @@ Get the close-on-exec flag associated wi
 .Fa fd
 as
 .Dv FD_CLOEXEC .
-If the returned value ANDed with
-.Dv FD_CLOEXEC
-is 0,
-the file will remain open across
+If the returned value is 0, the file will remain open across
 .Fn exec ,
 otherwise the file will be closed upon execution of
 .Fn exec


-- 
Matthieu Herrb

iwm(4) panic using wpa2 enterprise

[Matthieu Herrb]

;Intel Rate Matching Hub" rev 
2.00/0.04 addr 2
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
sd1 at scsibus3 targ 1 lun 0:  SCSI2 0/direct fixed
sd1: 235839MB, 512 bytes/sector, 482999472 sectors
root on sd1a (51923af16755d8a7.a) swap on sd1b dump on sd1b
iwm0: hw rev 0x140, fw ver 16.242414.0, address 7c:7a:91:ef:4e:d0

-- 
Matthieu Herrb

Re: Radeon HD 5450 panic

[Matthieu Herrb]

On Tue, Mar 20, 2018 at 09:11:42AM -0600, Anthony J. Bentley wrote:
> Hi Bryan,
> 
> Bryan Steele writes:
> > I think I had the same problem with:
> >
> >   radeondrm0 at pci1 dev 5 function 0 "ATI Radeon HD 3000" rev 0x00
> >
> > I believe it's related to the radeon(4) driver switching to glamor by
> > default on older families instead of EXA. I believe I saw this before
> > on the older driver manually testing out glamor, so it may be our
> > kernel radeondrm isn't ready for it..
> >
> > I could also reproduce it by producing lots text in an xterm, for
> > example objdump -d on a large binary.
> >
> > Section "Device"
> > Identifier  "Card0"
> > Driver  "radeon"
> > Option  "AccelMethod" "EXA" # or glamor
> > EndSection
> >
> > Worksaround it for me at least..
> 
> Same here: after switching to EXA, I can no longer reproduce the hang.

Hi,

the patch below makes the radeon driver default to EXA accel, except
for newer chipsets where only glamor is supported.

Index: src/radeon_glamor.c
===
RCS file: /cvs/OpenBSD/xenocara/driver/xf86-video-ati/src/radeon_glamor.c,v
retrieving revision 1.7
diff -u -p -u -r1.7 radeon_glamor.c
--- src/radeon_glamor.c 13 Mar 2018 06:13:14 -  1.7
+++ src/radeon_glamor.c 20 Mar 2018 20:00:33 -
@@ -86,7 +86,7 @@ radeon_glamor_pre_init(ScrnInfoPtr scrn)
s = xf86GetOptValString(info->Options, OPTION_ACCELMETHOD);
if (!s) {
if (xorgGetVersion() >= XORG_VERSION_NUMERIC(1,18,3,0,0)) {
-   if (info->ChipFamily < CHIP_FAMILY_R600)
+   if (info->ChipFamily < CHIP_FAMILY_TAHITI)
return FALSE;
} else {
if (info->ChipFamily < CHIP_FAMILY_TAHITI)

-- 
Matthieu Herrb

Re: firefox (or some rthread / network stuff) broken in -current

[Matthieu Herrb]

On Sun, Feb 11, 2018 at 02:50:30PM +0100, Martin Pieuchot wrote:
> On 11/02/18(Sun) 12:37, Matthieu Herrb wrote:
> > Hi,
> > 
> > I ugraded my laptop from sources to -current yesterday. Since then
> > firefox stops resolving host names after a dozen of minutes or so.
> 
> What do you mean with "stops resolving host names"?  What happens?  What
> do you see?
> 
> How did figure out it was a name resolution problem?
> 
> A firefox error page?
>  
> You saw some  syscalls failing via ktrace? 
> 
> You looked at tcpdump outputs?
> 
> Some network counters were increasing?
> 
> > It's not the firefox port itself, since it started after I rebooted a
> > the new kernel, while base and xenocara were rebuilding. My previous
> > kernel was from jan, 31.
> 
> So you're saying that *some* kernels newer than jan, 31 expose this
> regression?  Could you bisect when it has been introduced?
> 
> > Other programs are fine (including chromium), but appart may be chromium
> > nothing I run is using threads and name resolution at the same time .
> 
> You're assuming it's related to threaded applications,  why?
> 
> > Any idea of what's causing this, or should I start bisecting ?
> 
> A bisection would be great.

And the winner is:
https://github.com/openbsd/src/commit/a0801e345934b8c139c255c8327f726a614b3267

Author: mpi <m...@openbsd.org>
Date:   Fri Feb 9 07:32:35 2018 +

Call socreate() before falloc() in sys_socket().

This is similar to what we do in sys_socketpair() and will allow us
to grab the KERNEL_LOCK() only after having created a socket.

ok tedu@

Reverting that commit with the patch below, I've not been able to
reproduce the issue in -current.

Index: uipc_syscalls.c
===
RCS file: /cvs/OpenBSD/src/sys/kern/uipc_syscalls.c,v
retrieving revision 1.163
diff -u -r1.163 uipc_syscalls.c
--- uipc_syscalls.c 9 Feb 2018 07:32:35 -   1.163
+++ uipc_syscalls.c 11 Feb 2018 20:56:24 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: uipc_syscalls.c,v 1.163 2018/02/09 07:32:35 mpi Exp $ */
+/* $OpenBSD: uipc_syscalls.c,v 1.162 2018/01/09 15:14:23 mpi Exp $ */
 /* $NetBSD: uipc_syscalls.c,v 1.19 1996/02/09 19:00:48 christos Exp $  
*/
 
 /*
@@ -83,7 +83,7 @@
struct file *fp;
int type = SCARG(uap, type);
int domain = SCARG(uap, domain);
-   int fd, cloexec, nonblock, fflag, error;
+   int fd, error;
unsigned int ss = 0;
 
if ((type & SOCK_DNS) && !(domain == AF_INET || domain == AF_INET6))
@@ -95,24 +95,23 @@
if (error)
return (error);
 
-   type &= ~(SOCK_CLOEXEC | SOCK_NONBLOCK | SOCK_DNS);
-   cloexec = (SCARG(uap, type) & SOCK_CLOEXEC) ? UF_EXCLOSE : 0;
-   nonblock = SCARG(uap, type) &  SOCK_NONBLOCK;
-   fflag = FREAD | FWRITE | (nonblock ? FNONBLOCK : 0);
-
-   error = socreate(SCARG(uap, domain), , type, SCARG(uap, protocol));
+   fdplock(fdp);
+   error = falloc(p, (type & SOCK_CLOEXEC) ? UF_EXCLOSE : 0, , );
+   fdpunlock(fdp);
if (error != 0)
goto out;
 
-   fdplock(fdp);
-   error = falloc(p, cloexec, , );
-   fdpunlock(fdp);
+   fp->f_flag = FREAD | FWRITE | (type & SOCK_NONBLOCK ? FNONBLOCK : 0);
+   fp->f_type = DTYPE_SOCKET;
+   fp->f_ops = 
+   error = socreate(SCARG(uap, domain), ,
+   type & ~(SOCK_CLOEXEC | SOCK_NONBLOCK | SOCK_DNS), SCARG(uap, 
protocol));
if (error) {
-   soclose(so);
+   fdplock(fdp);
+   fdremove(fdp, fd);
+   closef(fp, p);
+   fdpunlock(fdp);
} else {
-   fp->f_flag = fflag;
-   fp->f_type = DTYPE_SOCKET;
-   fp->f_ops = 
if (type & SOCK_NONBLOCK)
so->so_state |= SS_NBIO;
so->so_state |= ss;


-- 
Matthieu Herrb

Re: firefox (or some rthread / network stuff) broken in -current

[Matthieu Herrb]

On Sun, Feb 11, 2018 at 04:51:47PM +0100, Landry Breuil wrote:
> On Sun, Feb 11, 2018 at 03:13:07PM +0100, Matthieu Herrb wrote:
> > On Sun, Feb 11, 2018 at 02:50:30PM +0100, Martin Pieuchot wrote:
> > > On 11/02/18(Sun) 12:37, Matthieu Herrb wrote:
> > > > Hi,
> > > > 
> > > > I ugraded my laptop from sources to -current yesterday. Since then
> > > > firefox stops resolving host names after a dozen of minutes or so.
> > > 
> > > What do you mean with "stops resolving host names"?  What happens?  What
> > > do you see?
> > > 
> > > How did figure out it was a name resolution problem?
> > > 
> > > A firefox error page?
> > 
> > Firefox says 'Resolving herrb.net' in popup  message area at the
> > bottom of the windows, plays the little animation with a dot moving
> > left to right and back in the tab, and the tab stays blank.
> 
> Im seeing the same thing right now, and it is 'by periods'. Are you
> using wifi or wired ? Here over iwm, and a kernel from yesterday.

wifi over iwm too. 
-- 
Matthieu Herrb

Re: firefox (or some rthread / network stuff) broken in -current

[Matthieu Herrb]

On Sun, Feb 11, 2018 at 02:50:30PM +0100, Martin Pieuchot wrote:
> On 11/02/18(Sun) 12:37, Matthieu Herrb wrote:
> > Hi,
> > 
> > I ugraded my laptop from sources to -current yesterday. Since then
> > firefox stops resolving host names after a dozen of minutes or so.
> 
> What do you mean with "stops resolving host names"?  What happens?  What
> do you see?
> 
> How did figure out it was a name resolution problem?
> 
> A firefox error page?

Firefox says 'Resolving herrb.net' in popup  message area at the
bottom of the windows, plays the little animation with a dot moving
left to right and back in the tab, and the tab stays blank.

>  
> You saw some  syscalls failing via ktrace?

Yes I say read on fd 9 failing with egain. this is a unix socket but
I don't know how to figure out the path with fstat. 
> 
> You looked at tcpdump outputs?

No visible port 53 activity while this happens
> 
> Some network counters were increasing?

I haven't looked at other data.

> 
> > It's not the firefox port itself, since it started after I rebooted a
> > the new kernel, while base and xenocara were rebuilding. My previous
> > kernel was from jan, 31.
> 
> So you're saying that *some* kernels newer than jan, 31 expose this
> regression?  Could you bisect when it has been introduced?

> 
> > Other programs are fine (including chromium), but appart may be chromium
> > nothing I run is using threads and name resolution at the same time .
> 
> You're assuming it's related to threaded applications,  why?

Because ssh, ftp or dig do resolve names without issues. 
> 
> > Any idea of what's causing this, or should I start bisecting ?
> 
> A bisection would be great.

That's what I'm doing now. Before starting I was looking for obvious
changes during the a2k18 that I may try to remove before doing the
bissect, since the problem takes some time to manifest.

Kettenis suggested the libc/asr commit, it's not this since I could
reproduce the problem without this commit.

I'm currently on a kernel that seems ok:
https://github.com/openbsd/src/commit/54fc14edb8e865a7c7cea20937dce12585b31555

-- 
Matthieu Herrb

Re: firefox (or some rthread / network stuff) broken in -current

[Matthieu Herrb]

On Sun, Feb 11, 2018 at 01:09:36PM +0100, Mark Kettenis wrote:
> > From: "Peter N. M. Hansteen" <pe...@bsdly.net>
> > Date: Sun, 11 Feb 2018 12:49:49 +0100
> > 
> > n 02/11/18 12:37, Matthieu Herrb wrote:
> > > I ugraded my laptop from sources to -current yesterday. Since then
> > > firefox stops resolving host names after a dozen of minutes or so.
> > > The network.dnsCacheExpiration=0 setting mentionned by phessler on
> > > mastodon doesn't help.
> > > 
> > > It's not the firefox port itself, since it started after I rebooted a
> > > the new kernel, while base and xenocara were rebuilding. My previous
> > > kernel was from jan, 31.
> > 
> > I'm seeing the same thing here, but I jump snapshot to snapshot on my
> > laptop and I saw this change after upgrading to the February 10 snapshot
> > 
> > > Other programs are fine (including chromium), but appart may be chromium
> > > nothing I run is using threads and name resolution at the same time .
> > 
> > For some reason the most clearly affected ones are firefox and
> > thunderbird, but even name resolution from the shell and things like
> > pkg_add seem to resolve names slower than they used to.
> 
> Does reverting the libc asr changes help?

Unfortunatly, no.

-- 
Matthieu Herrb

firefox (or some rthread / network stuff) broken in -current

[Matthieu Herrb]

Hi,

I ugraded my laptop from sources to -current yesterday. Since then
firefox stops resolving host names after a dozen of minutes or so.
The network.dnsCacheExpiration=0 setting mentionned by phessler on
mastodon doesn't help.

It's not the firefox port itself, since it started after I rebooted a
the new kernel, while base and xenocara were rebuilding. My previous
kernel was from jan, 31.

Other programs are fine (including chromium), but appart may be chromium
nothing I run is using threads and name resolution at the same time .

Any idea of what's causing this, or should I start bisecting ?

-- 
Matthieu Herrb