Re: Dual external monitors not working since drm 5.10.47 upgrade
On 9/8/22 03:07, Jonathan Gray wrote: Index: sys/dev/pci/drm/i915/i915_drv.c === RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v retrieving revision 1.143 diff -u -p -r1.143 i915_drv.c --- sys/dev/pci/drm/i915/i915_drv.c 30 Jul 2022 14:15:20 - 1.143 +++ sys/dev/pci/drm/i915/i915_drv.c 8 Sep 2022 00:33:22 - @@ -2410,6 +2410,11 @@ inteldrm_attach(struct device *parent, s dev_priv->id = id; info = (struct intel_device_info *)id->driver_data; + /* Device parameters start as a copy of module parameters. */ + i915_params_copy(_priv->params, _modparams); + dev_priv->params.enable_guc = 0; + dev_priv->params.request_timeout_ms = 0; + /* Setup the write-once "constant" device info */ device_info = mkwrite_device_info(dev_priv); memcpy(device_info, info, sizeof(*device_info)); This is cleaner and simpler than what I'd suggested. MST continues to work OK, and I haven't seen anything break as a result of the change. I did however notice that on a couple of shutdowns I got some additional console messages, although this _might_ be related to me having disabled MST in my primary display between boot and shutdown. drm:pid8902:drm_dp_check_act_status *ERROR* [drm] *ERROR* Failed to get ACT after 3000ms, last status: 04 drm:pid8902:drm_dp_check_act_status *ERROR* [drm] *ERROR* Failed to get ACT after 3000ms, last status: 04 drm:pid8902:drm_dp_check_act_status *ERROR* [drm] *ERROR* Failed to get ACT after 3000ms, last status: 04 I also tested the use of concurrent DP and HDMI outputs on my T470 dock. Initially I thought that this wasn't working, but I am using a dock with 2xDP + 1xHDMI, and it seems like not all outputs are able to be used concurrently. So..dual displays with DP & HDMI works OK if I use a specific DP port on the back of the dock. There does also appear to be some fudging going on with output names in xrandr when running via the dock: the HDMI port is presented as DP output. I suspect that this might be due to the internals of the dock, though. I've also checked that things work with the laptop undocked...but realised that it only has a single HDMI output. That works fine, and xrandr reports the output as HDMI-2. This does however seem to stop working if the laptop is subsequently docked, with xrandr then reporting that HDMI-2 is disconnected. This may also just be normal behaviour for a docked laptop. Unfortunately there's now so much console output during startup that dmesg appears to be truncated - so I don't have a full dmesg to share after applying the new patch. I searched quickly for instructions on increasing the buffer size but only found a post from jj@ from 2006 (!). Given that things seem to work OK now I suppose that there's little interest in seeing a dmesg anyway, but I'm happy to provide one if it's useful. Thanks again for the support to investigate this. Paul
Re: Dual external monitors not working since drm 5.10.47 upgrade
On 9/7/22 13:05, Jonathan Gray wrote:
If you add "option DRMDEBUG" to your kernel config
there may be some hints in the (large amount of) dmesg output
Also build with this to add some more DP messages.
Used in sys/dev/pci/drm/drm_dp_mst_topology.c
Index: sys/dev/pci/drm/drm_print.c
===
RCS file: /cvs/src/sys/dev/pci/drm/drm_print.c,v
retrieving revision 1.4
diff -u -p -r1.4 drm_print.c
--- sys/dev/pci/drm/drm_print.c 12 Jun 2020 10:06:40 - 1.4
+++ sys/dev/pci/drm/drm_print.c 7 Sep 2022 10:38:00 -
@@ -43,7 +43,7 @@
* Bitmask of DRM_UT_x. See include/drm/drm_print.h for details.
*/
#ifdef DRMDEBUG
-unsigned int __drm_debug = DRM_UT_DRIVER | DRM_UT_KMS;
+unsigned int __drm_debug = DRM_UT_DRIVER | DRM_UT_KMS | DRM_UT_DP;
#else
unsigned int __drm_debug;
#endif
Thanks; I think I have identified the problem.
I rebuilt against -current with the suggested modifications. This is
tested on the HP ProDesk w/ 1x DP + 1x VGA output; only the DP output is
in use, and it's connected to a monitor with MST enabled. I've included
the dmesg output at the bottom.
I've noticed that DP MST seems to be supported by both port and sink
(host system and monitor respectively, I am guessing). However, it's
being administratively disabled via a check on the following variable:
i915->params.enable_dp_mst (see "modparam:no" in the log message below).
[drm] [ENCODER:73:DDI B/PHY B] MST support: port: yes, sink: yes, modparam: no
Digging a bit further...the params struct is defined in i915_params.h,
and its members are initialised to specific values that are subsequently
used as the initial configuration for i915 devices in Linux (see call to
i915_params_copy() in i915_drv.c). This is however not performed under
OpenBSD, because it's buried in an #ifdef __linux__ section. So it looks
like we are simply missing some intended default configuration.
I've included a bodge below to ignore enable_dp_mst entirely, and I have
confirmed that this restores my ability to run with DisplayPort MST. I
am assuming that it's safe to set enable_dp_mst true by default in
OpenBSD, but that seems unlikely to help other users who are not relying
on MST for multi-screen support.
My initial approach to fix this properly would be to introduce
OpenBSD-conditional config into i915_params.h and then update
i915_driver_probe() so that it calls i915_params_copy() early. Then it
would be possible to incrementally identify which defaults are
appropriate. If that's acceptable then I'm happy to prepare a diff for
testing.
Thanks again for the tips to investigate this - it's a great relief to
have understood the issue and it will be nice to get use of my second
screen again.
Paul
Hacked diff:
diff --git a/sys/dev/pci/drm/drm_print.c b/sys/dev/pci/drm/drm_print.c
index b251af66c24..bdd49c47e94 100644
--- a/sys/dev/pci/drm/drm_print.c
+++ b/sys/dev/pci/drm/drm_print.c
@@ -43,7 +43,7 @@
* Bitmask of DRM_UT_x. See include/drm/drm_print.h for details.
*/
#ifdef DRMDEBUG
-unsigned int __drm_debug = DRM_UT_DRIVER | DRM_UT_KMS;
+unsigned int __drm_debug = DRM_UT_DRIVER | DRM_UT_KMS | DRM_UT_DP;
#else
unsigned int __drm_debug;
#endif
diff --git a/sys/dev/pci/drm/i915/display/intel_dp.c
b/sys/dev/pci/drm/i915/display/intel_dp.c
index 465cb36bb22..3ad99ae903d 100644
--- a/sys/dev/pci/drm/i915/display/intel_dp.c
+++ b/sys/dev/pci/drm/i915/display/intel_dp.c
@@ -2563,8 +2563,7 @@ intel_dp_can_mst(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- return i915->params.enable_dp_mst &&
- intel_dp->can_mst &&
+ return intel_dp->can_mst &&
drm_dp_read_mst_cap(_dp->aux, intel_dp->dpcd);
}
@@ -2585,8 +2584,7 @@ intel_dp_configure_mst(struct intel_dp *intel_dp)
if (!intel_dp->can_mst)
return;
- intel_dp->is_mst = sink_can_mst &&
- i915->params.enable_dp_mst;
+ intel_dp->is_mst = sink_can_mst;
drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
intel_dp->is_mst);
Full dmesg w/ drm debug enabled:
OpenBSD 7.2-beta (CUSTOM.MP) #0: Wed Sep 7 14:59:56 CEST 2022
bui...@buildy.xyz:/usr/src/sys/arch/amd64/compile/CUSTOM.MP
real mem = 8363495424 (7976MB)
avail mem = 8092405760 (7717MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xc39a1000 (51 entries)
bios0: vendor HP version "N23 Ver. 02.56" date 04/08/2022
bios0: HP HP ProDesk 400 G2 MINI
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT UEFI SSDT MSDM SLIC WSMT HPET APIC MCFG
SSDT SSDT SSDT DMAR FPDT BGRT
acpi0: wakeup devices PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) PEG0(S4)
PEGP(S4) GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4)
PXSX(S4) RP03(S4) PXSX(S4) [...]
acpitimer0
Re: Dual external monitors not working since drm 5.10.47 upgrade
Hey Julian, On 9/4/22 18:18, Julian Huhn wrote: Moin! I can reproduce with my X270. With -current it does not work and with 6.9 both external monitors run without problems. Same problem as I had already mentioned here: https://marc.info/?l=openbsd-misc=166153179211227=2 Ah, I'd seen your post but was thrown off by the mention of Thunderbolt, and hadn't noticed that you had also tried with a non-Thunderbolt dock. Thanks for confirming that it previously worked OK on your X270. I've been searching for additional reports, and it seems as though the Intel 4xxx CPU series w/ HD Graphics 4400 might also be impacted. Here is a user on reddit writing about similar symptoms on a Lenovo T440p: https://www.reddit.com/r/openbsd/comments/ws1j1d/double_displayport_dock/ Paul
Dual external monitors not working since drm 5.10.47 upgrade
Hi misc@, I'm writing to report a problem with external monitors that is impacting two of my amd64 systems. The two affected systems that I have are: - Lenovo T470 (Intel i7-7600 w/ HD Graphics 620) - HP ProDesk 400 G2 Mini (Intel i5-6500T w/ HD Graphics 530) The issues that I am experiencing are: - Only a single external display works via DisplayPort/HDMI. - Additional external displays show only duplicate output of the first. - DisplayPort MST (daisy chain) no longer works. After having had a working setup with 2 x 1920x1200 displays connected via DisplayPort MST, my dual screen setup stopped working correctly in August 2021 after an update to a 6.9-current snapshot. I had previously provided input to a report of similar symptoms from Alexis de Bruyn in ~October 2021, but never got any feedback and didn't have capacity to take it any further at the time: https://marc.info/?l=openbsd-misc=163569235820627=2 After deferring a deeper investigation for far too long, I have now confirmed that the issue appears in my systems after the drm update that was applied on July 7, 2021: update drm to linux 5.10.47 hardware support changes include inteldrm: better support for tiger lake amdgpu: support for navi12, navi21 "sienna_cichlid", arcturus amdgpu: support for cezanne "green sardine" ryzen 5000 apu Thanks to the OpenBSD Foundation for sponsoring this work, patrick@ for helping adapt rockchip drm, kettenis@ and mpi@ for uvm discussions and various testers. https://github.com/openbsd/src/commit/ad8b1aafbcc34f7eb86e4ebfd874be286017954b There was speculation in the previously mentioned misc report that the error might have related to an inteldrm firmware upgrade from around the same time. I have reproduced the issue with the following firmware installed, and I do not believe that the ultimate bump in firmware versions in OpenBSD 7.0 are related to this problem. inteldrm-firmware-20201218 firmware binary images for inteldrm(4) driver I also confirm that this error persists on my T470 running a very recent snap and the latest firmware: OpenBSD 7.2-beta (GENERIC.MP) #706: Tue Aug 23 12:33:39 MDT 2022 I've included the following outputs from the HP ProDesk system (before and after the drm 5.10.47 update). - dmesg - Xorg.0.log - xrandr Relating to these outputs, the main observation that I have is that the interface naming for DisplayPort MST changed (i.e. "DP-1-1" became simply "DP-1"). It goes without saying that the fact that this report is so late inevitably makes it more difficult to investigate, since the drm codebase has been updated to 5.15.14 in the time since the initial report. Additionally, the breaking change itself was extremely large and contained a major change to the drm subsystem. However, it still seems worthwhile to report since this behaviour is still present in recent snapshots, and the affected hardware is still very capable. I have a dedicated system available for testing this if the need arises and I'm happy to provide any further information about my setup if required. Thanks, Paul before upgrade to linux drm 5.10.47 dmesg: OpenBSD 6.9-current (GENERIC.MP) #0: Fri Sep 2 00:15:41 CEST 2022 bui...@buildy.xyz:/sys/arch/amd64/compile/GENERIC.MP real mem = 8363495424 (7976MB) avail mem = 8094556160 (7719MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xc39a1000 (51 entries) bios0: vendor HP version "N23 Ver. 02.53" date 04/16/2021 bios0: HP HP ProDesk 400 G2 MINI acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT UEFI SSDT SSDT MSDM SLIC WSMT HPET APIC MCFG SSDT SSDT SSDT DMAR FPDT BGRT acpi0: wakeup devices PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) PEG0(S4) PEGP(S4) GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-6500T CPU @ 2.50GHz, 2395.31 MHz, 06-5e-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT, DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1, SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE, PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX, BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT, PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT, XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock
Re: inteldrm extended display regression
Hi Alexis, On 10/31/21 14:33, Alexis de BRUYN wrote: Hello Everyone, Since june 2021, following -current, I am not able to get one extended display on a 3-monitor setup (with arandr) : * Lenovo ThinkPad Thunderbolt 3 Dock Gen 2 (DK1841) + 3 identical monitors ; * Lenovo ThinkPad X1 Carbon 6th Generation Laptop (Type 20KH-006GFR) ; The display is cloned on each of the 3 external monitors (dmesg, Xorg.0.log, xrandr outputs below). With a live OpenBSD 6.9-stable (+ intel-firmware-20210608v0 + inteldrm-firmware-20201218), all is still working fine as before (dmesg, Xorg.0.log, xrandr outputs below) without specific xrandr/arandr/xorg.conf. I have tested yesterday with a fresh snapshot but I still have disconnected "Output DP-1-x". Is it an intel-firmware-20210608 issue on 7.0-current or am I missing something with a configuration file ? I have two PCs running OpenBSD 7.0-current with the same symptoms: - Lenovo T470 + dock (Intel HD Graphics 620) - HP ProDesk 400 G2 Mini (Intel HD Graphics 530) Both devices are only able to detect a maximum of 1 external screen. For the HP ProDesk, I was previously using DisplayPort Daisy Chaining, with two 2 x 24" screens @ 1920x1200 75Hz. This had been working fine with 6.9-current earlier in the year (i.e. before June?), but I noticed that it stopped working correctly back in ~July/August after I updated. Unfortunately I haven't found the time to troubleshoot it further to identify exactly which snapshot resulted in changed behaviour. For the T470, I have only now connected it to an external screen and observed that the same issue occurs - only 1 external screen detected, DP Daisy Chain not working. I had assumed that the issue was related to the bump to Linux DRM 5.10.x in July (https://marc.info/?l=openbsd-cvs=162562554228908=2), but your investigation would seem to rule that out. Also, xrandr and dmesg below. Paul xrandr for the T470 w/ 2 * 24" 1920*1200@75Hz LCDs connected (1 DP each). eDP-1 (T470 LCD) is forcibly disabled, and the 2nd LCD screen is just a clone of the first. # xrandr Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 16384 x 16384 eDP-1 connected primary (normal left inverted right x axis y axis) 1920x1080 60.01 + 60.0159.9759.9659.93 1680x1050 59.9559.88 1400x1050 59.98 1600x900 59.9959.9459.9559.82 1280x1024 60.02 1400x900 59.9659.88 1280x960 60.00 1440x810 60.0059.97 1368x768 59.8859.85 1280x800 59.9959.9759.8159.91 1280x720 60.0059.9959.8659.74 1024x768 60.0460.00 960x720 60.00 928x696 60.05 896x672 60.01 1024x576 59.9559.9659.9059.82 960x600 59.9360.00 960x540 59.9659.9959.6359.82 800x600 60.0060.3256.25 840x525 60.0159.88 864x486 59.9259.57 700x525 59.98 800x450 59.9559.82 640x512 60.02 700x450 59.9659.88 640x480 60.0059.94 720x405 59.5158.99 684x384 59.8859.85 640x400 59.8859.98 640x360 59.8659.8359.8459.32 512x384 60.00 512x288 60.0059.92 480x270 59.6359.82 400x300 60.3256.34 432x243 59.9259.57 320x240 60.05 360x202 59.5159.13 320x180 59.8459.32 DP-1 disconnected (normal left inverted right x axis y axis) HDMI-1 disconnected (normal left inverted right x axis y axis) DP-2 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 59.95*+ 3840x1200 60.00 2560x1024 60.00 1680x1050 59.95 1280x1024 75.0260.02 1440x900 59.89 1024x768 75.0360.00 800x600 75.0060.32 640x480 75.0060.0059.94 HDMI-2 disconnected (normal left inverted right x axis y axis) Dmesg for the T470 (including in/out of dock a couple of time): OpenBSD 7.0-current (GENERIC.MP) #81: Mon Nov 8 11:07:59 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 33965465600 (32391MB) avail mem = 32920043520 (31395MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xca2fc000 (62 entries) bios0: vendor LENOVO version "N1QET91W (1.66 )" date 04/26/2021 bios0: LENOVO 20HD000LUK acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT SSDT BOOT BATB SLIC SSDT SSDT SSDT WSMT SSDT SSDT DBGP DBG2 MSDM DMAR ASF! FPDT UEFI acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) RP02(S4) RP03(S4) RP04(S4) RP05(S4) RP06(S4) RP08(S4) RP09(S4 ) RP10(S4) RP11(S4) RP12(S4) RP13(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at
Small fix for www/faq/faq7.html
Hi misc, www/faq/faq7.html links to termcap(5) but the link is simply http://man.openbsd.org/termcap, which ends up at termcap(3). A diff is included below. Also an observation: on faq7.html linked text often specify the specific section that is being linked, but the actual links often do not. For instance: $ grep man.openbsd.org www/faq/faq7.html | head -n 10 http://man.openbsd.org/wscons;>wscons(4) console driver. http://man.openbsd.org/wsconsctl;>wsconsctl(8) utility. http://man.openbsd.org/wsconsctl;>wsconsctl(8), http://man.openbsd.org/wsmoused;>wsmoused(8). http://man.openbsd.org/rcctl;>rcctl(8) utility. http://man.openbsd.org/vga;>vga(4) http://man.openbsd.org/drm;>drm(4). http://man.openbsd.org/vga;>vga(4) use the http://man.openbsd.org/wsconscfg;>wsconscfg(8) http://man.openbsd.org/rc.local;>rc.local(8) Most of the time there are no collisions, but sometimes there are (as in the case of termcap). Is it a worthwhile exercise to update the links to ensure that they point at the right sections? Paul Index: www/faq/faq7.html === RCS file: /cvs/www/faq/faq7.html,v retrieving revision 1.124 diff -u -p -r1.124 faq7.html --- www/faq/faq7.html 18 Jun 2016 03:40:49 - 1.124 +++ www/faq/faq7.html 1 Aug 2016 19:33:04 - @@ -273,7 +273,7 @@ tty00 "/usr/libexec/getty std.9600" Here, tty00 is the serial port we are using as a console. vt220 is the -http://man.openbsd.org/termcap;>termcap(5) +http://man.openbsd.org/termcap.5;>termcap(5) entry that matches YOUR terminal (other likely options might include vt100, xterm, etc.). The on bit activates the
Re: patch: fix usage of mkstemp() in rdistd
On 03/28/16 04:05, Todd C. Miller wrote:
> I think it's best to just check the parent directories first and
> then create the temp name.
>
> - todd
This works for me and avoids my hacking around with new. I added a few
extra destination directories and it seems to hold up OK. Thanks!
paul@tiger:~/workspace/push/cm: /usr/bin/rdist -L syslog=all -d
HOST=aspireone
aspireone: updating host aspireone
aspireone: ./scripts: installing
aspireone: scripts: mkdir
aspireone: ./scripts/util: installing
aspireone: ./scripts/install: installing
aspireone: ./scripts/files: installing
aspireone: ./hosts/aspireone/etc/doas.conf: installing
aspireone: staging: mkdir
aspireone: staging/etc: mkdir
aspireone: staging/etc/one: mkdir
aspireone: staging/etc/one/two: mkdir
aspireone: staging/etc/one/two/three: mkdir
aspireone: ./hosts/aspireone/etc/rc.conf.local: installing
aspireone: cmdspecial "./scripts/install"
> Index: server.c
> ===
> RCS file: /cvs/src/usr.bin/rdistd/server.c,v
> retrieving revision 1.40
> diff -u -p -u -r1.40 server.c
> --- server.c 22 Dec 2015 08:48:39 - 1.40
> +++ server.c 28 Mar 2016 02:01:32 -
> @@ -750,12 +750,9 @@ recvfile(char *new, opt_t opts, int mode
>/*
> * Create temporary file
> */
> - if ((f = mkstemp(new)) < 0) {
> - if (errno != ENOENT || chkparent(new, opts) < 0 ||
> - (f = mkstemp(new)) < 0) {
> - error("%s: create failed: %s", new, SYSERR);
> - return;
> - }
> + if (chkparent(new, opts) < 0 || (f = mkstemp(new)) < 0) {
> + error("%s: create failed: %s", new, SYSERR);
> + return;
>}
>
>/*
> @@ -1161,13 +1158,10 @@ recvlink(char *new, opt_t opts, int mode
>/*
> * Make new symlink using a temporary name
> */
> - if (mktemp(new) == NULL || symlink(dbuf, new) < 0) {
> - if (errno != ENOENT || chkparent(new, opts) < 0 ||
> - mktemp(new) == NULL || symlink(dbuf, new) < 0) {
> - error("%s -> %s: symlink failed: %s", new, dbuf,
> - SYSERR);
> - return;
> - }
> + if (chkparent(new, opts) < 0 || mktemp(new) == NULL ||
> + symlink(dbuf, new) < 0) {
> + error("%s -> %s: symlink failed: %s", new, dbuf, SYSERR);
> + return;
>}
>
>/*
Re: patch: fix usage of mkstemp() in rdistd
I had a request for more information about how to replicate this. Here's
a stripped back example that demonstrates the problem.
paul@tiger:~/workspace/push/cm: cat ./distfile
./hosts/aspireone/etc/doas.conf -> ${HOST}
install staging/etc ;
paul@tiger:~/workspace/push/cm: cat ./hosts/aspireone/etc/doas.conf
# This is a dummy file.
First attempt fails to create a file if two new directories have been
created:
paul@tiger:~/workspace/push/cm: /usr/bin/rdist -L syslog=all -d
HOST=aspireone
aspireone: updating host aspireone
aspireone: ./hosts/aspireone/etc/doas.conf: installing
aspireone: staging: mkdir
aspireone: staging/etc: mkdir
aspireone: REMOTE ERROR: staging/etc/rdist9lu2tvqg: create failed:
Invalid argument
aspireone: updating of aspireone finished
Second pass succeeds:
paul@tiger:~/workspace/push/cm: /usr/bin/rdist -L syslog=all -d
HOST=aspireone
aspireone: updating host aspireone
aspireone: ./hosts/aspireone/etc/doas.conf: installing
aspireone: updating of aspireone finished
dmesg from the remote machine:
OpenBSD 5.8-stable (GENERIC.MP) #1: Thu Nov 12 09:27:53 CET 2015
paul@buildbox:/usr/src/sys/arch/i386/compile/GENERIC.MP
RTC BIOS diagnostic error 80
cpu0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz ("GenuineIntel" 686-class)
1.60 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MO
VBE,LAHF,PERF,SENSOR
real mem = 1596956672 (1522MB)
avail mem = 1552547840 (1480MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 10/06/08, SMBIOS rev. 2.4 @ 0xe9180 (32 entries)
bios0: vendor Acer version "v0.3309" date 10/06/2008
bios0: Acer AOA150
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT HPET APIC MCFG ASF! SLIC BOOT
acpi0: wakeup devices P32_(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3)
ECHI(S3) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) AZAL(S0) MODM(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 132MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU N270 @ 1.60GHz ("GenuineIntel" 686-class)
1.60 GHz
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MO
VBE,LAHF,PERF,SENSOR
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 4
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 5 (P32_)
acpiprt2 at acpi0: bus 1 (EXP1)
acpiprt3 at acpi0: bus 2 (EXP2)
acpiprt4 at acpi0: bus 3 (EXP3)
acpiprt5 at acpi0: bus 4 (EXP4)
acpiec0 at acpi0
acpicpu0 at acpi0: !C3(100@57 io@0x416), !C2(500@1 io@0x414), C1(1000@1
halt), PSS
acpicpu1 at acpi0: !C3(100@57 io@0x416), !C2(500@1 io@0x414), C1(1000@1
halt), PSS
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: LID0
acpibtn2 at acpi0: SLPB
acpibat0 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpivideo0 at acpi0: OVGA
bios0: ROM list: 0xc/0xec00!
cpu0: Enhanced SpeedStep 1596 MHz: speeds: 1600, 1333, 1066, 800 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945GME Host" rev 0x03
vga1 at pci0 dev 2 function 0 "Intel 82945GME Video" rev 0x03
intagp0 at vga1
agp0 at intagp0: aperture at 0x6000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1024x600
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
azalia0: codecs: Realtek ALC268
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 4 int 16
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 4 int 17
pci2 at ppb1 bus 2
2:0:0: mem address conflict 0xfffe/0x2
re0 at pci2 dev 0 function 0 "Realtek 8101E" rev 0x02: RTL8102EL
(0x2480), msi, address 00:1e:68:cc:c0:06
rlphy0 at re0 phy 7: RTL8201L 10/100 PHY, rev. 1
ppb2 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x02: apic 4 int 18
pci3 at ppb2 bus 3
wpi0 at pci3 dev 0 function 0 "Intel PRO/Wireless 3945ABG" rev 0x02:
msi, MoW1, address 00:1c:bf:a9:21:f8
ppb3 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x02: apic 4 int 19
pci4 at ppb3 bus 4
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 4 int 16
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 4 int 17
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 4 int 18
uhci3 at pci0 dev
patch: fix usage of mkstemp() in rdistd
Dear misc,
I am playing with rdist for some basic management of config files on
remote machines. I have run into an issue with rdistd where it
(apparently) has to create two or more directories in succession and
then copy files across to those newly created directories.
aspireone: updating host aspireone
aspireone: ./scripts: installing
aspireone: scripts: mkdir
aspireone: ./scripts/util: installing
aspireone: ./scripts/install: installing
aspireone: ./scripts/files: installing
aspireone: ./hosts/aspireone/etc/doas.conf: installing
aspireone: staging: mkdir
aspireone: staging/etc: mkdir
aspireone: REMOTE ERROR: staging/etc/rdistRWoWItah: create failed: Invalid
argument
aspireone: ./hosts/aspireone/etc/rc.conf.local: installing
In server.c recvfile(), a failed call to mkstemp() can result in a
second call to mkstemp() with an invalid template string. This is
because the first call to mkstemp() modifies the template string such
that it no longer contains the magic "".
I have included a diff (below) that seems to correct the behaviour by
restoring the template string before the second call to mkstemp(). I
haven't looked into why the first call to mkstemp() fails, but given the
existing handling of that I am assuming it's not totally unexpected.
Here is some log output after applying the patch:
> aspireone: updating host aspireone
> aspireone: ./scripts: installing
> aspireone: scripts: mkdir
> aspireone: ./scripts/util: installing
> aspireone: ./scripts/install: installing
> aspireone: ./scripts/files: installing
> aspireone: ./hosts/aspireone/etc/doas.conf: installing
> aspireone: staging: mkdir
> aspireone: staging/etc: mkdir
> aspireone: ./hosts/aspireone/etc/rc.conf.local: installing
Index: ./src/usr.bin/rdistd/server.c
===
RCS file: /cvs/src/usr.bin/rdistd/server.c,v
retrieving revision 1.40
diff -u -r1.40 server.c
--- ./src/usr.bin/rdistd/server.c 22 Dec 2015 08:48:39 - 1.40
+++ ./src/usr.bin/rdistd/server.c 27 Mar 2016 18:03:14 -
@@ -743,16 +743,24 @@
{
int f, wrerr, olderrno;
off_t i;
- char *cp;
+ char *cp, *tp;
char *savefile = NULL;
static struct stat statbuff;
/*
* Create temporary file
*/
+ tp = strstr(new, "XX");
if ((f = mkstemp(new)) < 0) {
- if (errno != ENOENT || chkparent(new, opts) < 0 ||
- (f = mkstemp(new)) < 0) {
+ if (errno != ENOENT || chkparent(new, opts) < 0) {
+ error("%s: create failed: %s", new, SYSERR);
+ return;
+ }
+ /* Restore the original template. */
+ for ( ; *tp; ++tp) {
+ *tp = 'X';
+ }
+ if ((f = mkstemp(new)) < 0) {
error("%s: create failed: %s", new, SYSERR);
return;
}
Re: Best OpenBSD cloud hosting?
On 9/10/2013 12:16 PM, openda...@hushmail.com wrote: Can anyone recommend a decent OpenBSD cloud hosting provider? CloudSigma do. Looks like you can do a short trial as well. http://www.cloudsigma.com/2013/09/26/running-freebsd-netbsd-and-openbsd-in-the-cloud/
Re: Interrupts cause uaudio stuttering with mpd
On 29/09/2013 7:28 PM, Alex Holst wrote: I'm looking for input on solving a long-standing issue with uaudio playback on my desktop system. (http://mongers.org/openbsd/dmesg.fit) When playing local FLAC files or streaming ogg/mp3 through mpd (or cvlc), I experience stuttering when system interrupts spike above 15% -- the most reliable way I can reproduce this is by forcing a bit of disk i/o. Back in April I tried Alexandre's patch related to audio/midi interrupts on mp kernels. I also tried sndiod -r44100 -z2940 but neither made any difference. Is the stuttering likely related to my hardware, is it a known problem or is there something else I can try? Sounds quite similar to this: http://marc.info/?l=openbsd-miscm=137935068413841w=2 If that is the case then I guess that upgrading from the Atom to a faster CPU might alleviate your symptoms, though difficult for me to say because the underlying issue sounds very complex. paul
Re: i386_set_ioperm and machdep.allowaperture
Dear list,
Here's a manpage diff for i386_get_ioperm(2) to reflect the behaviour I
have observed (see below diff). Please whack me with a stick if I have
made any obvious mistakes.
Index: src/lib/libarch/i386/i386_get_ioperm.2
===
RCS file: /cvs/src/lib/libarch/i386/i386_get_ioperm.2,v
retrieving revision 1.14
diff -u -r1.14 i386_get_ioperm.2
--- src/lib/libarch/i386/i386_get_ioperm.2 26 Jun 2008 05:42:04
- 1.14
+++ src/lib/libarch/i386/i386_get_ioperm.2 10 Sep 2013 07:08:23 -
@@ -50,7 +50,9 @@
.Fn i386_set_ioperm
sets the I/O permission bitmap from the data pointed to by
.Fa iomap .
-This call is restricted to the superuser.
+This call is restricted to the superuser and is only permitted when the
+.Va machdep.allowaperture
+sysctl is set to an non-zero value.
.Pp
The permission bitmap contains 1024 bits in 32 longwords.
If bit
@@ -82,8 +84,6 @@
.Va errno
is set to indicate the error.
.Sh ERRORS
-.Fn i386_get_ioperm
-and
.Fn i386_set_ioperm
will fail if:
.Bl -tag -width [EINVAL]
@@ -91,7 +91,9 @@
.Fa iomap
points outside the process's allocated address space.
.It Bq Er EPERM
-The caller was not the superuser.
+The caller was not the superuser or
+.Va machdep.allowaperture
+is not an non-zero value.
.El
.Sh SEE ALSO
.Xr i386_iopl 2
$ cat test_ioperm.c
#include sys/types.h
#include machine/sysarch.h
#include err.h
#include stdio.h
int
main() {
u_long iomap[32];
if (i386_get_ioperm(iomap) != 0) {
err(-1,i386_get_ioperm);
}
if (i386_set_ioperm(iomap) != 0) {
err(-1,i386_set_ioperm);
}
printf(i386_get_ioperm and i386_set_ioperm returned 0\n);
return 0;
}
$
$ gcc test_ioperm.c -o test_ioperm -li386
$ ./test_ioperm
test_ioperm: i386_set_ioperm: Operation not permitted
$ sudo ./test_ioperm
i386_get_ioperm and i386_set_ioperm returned 0
* Note the above tests were performed with machdep.allowaperture=2 in
/etc/sysctl.conf
Kind regards,
Paul
i386_set_ioperm and machdep.allowaperture
Dear list, I'm experimenting with i386_set_ioperm() on an old machine and I'm experiencing a problem. I'm running 5.3-RELEASE and dmesg is at the bottom. i386_get_ioperm correctly retrieves the permission map and returns 0. i386_set_operm returns -1 and sets errno to 1 (EPERM). This occurs when using it through sudo. man i386_set_ioperm says: i386_get_ioperm() and i386_set_ioperm() will fail if: [EFAULT] iomap points outside the process's allocated address space. [EPERM] The caller was not the superuser. Reading that man page led me to i386_iopl, which notes: This call may only be made by the superuser. Additionally, it is only permitted when the securelevel(7) is less than or equal to 0 or the machdep.allowaperture sysctl has been set to a non-zero value. Changing machdep.allowaperture to 2, as per the i386 X.Org readme [1], results in a successful call of i386_set_ioperm. It fails again if I toggle allowaperture back to 0. So, it seems that i386_set_ioperm might have the same constraint outlined above for i386_iopl. A post from a few years ago [2] seems to support that. Does that sound correct or am I missing something? Thanks! Paul [1] http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.i386 [2] http://marc.info/?l=openbsd-miscm=114692255503116w=2 [3] dmesg OpenBSD 5.3 (GENERIC) #50: Tue Mar 12 18:35:23 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) 4 CPU 1.70GHz (GenuineIntel 686-class) 1.70 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PERF real mem = 804831232 (767MB) avail mem = 780693504 (744MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 03/27/02, BIOS32 rev. 0 @ 0xf1050, SMBIOS rev. 2.3 @ 0xf3010 (51 entries) bios0: vendor Award Software, Inc. version ASUS P4B-MX ACPI BIOS Revision 1004 date 03/27/2002 bios0: ASUSTeK Computer INC. P4B-MX acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP BOOT APIC acpi0: wakeup devices PCI1(S4) PCI2(S4) USB0(S4) USB1(S4) PCI0(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 99MHz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PCI1) acpiprt2 at acpi0: bus 2 (PCI2) acpicpu0 at acpi0 acpibtn0 at acpi0: PWRB bios0: ROM list: 0xc/0x9000 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82845 Host rev 0x04 intelagp0 at pchb0 agp0 at intelagp0: aperture at 0xf800, size 0x400 ppb0 at pci0 dev 1 function 0 Intel 82845 AGP rev 0x04 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 Matrox MGA G400/G450 AGP rev 0x85 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb1 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0x12 pci2 at ppb1 bus 2 fxp0 at pci2 dev 8 function 0 Intel 82562 rev 0x03, i82562: apic 2 int 20, address 00:e0:18:87:d2:b1 inphy0 at fxp0 phy 1: i82562ET 10/100 PHY, rev. 0 malo0 at pci2 dev 10 function 0 Marvell Libertas 88W8335 rev 0x03: apic 2 int 22, address 00:1e:2a:47:39:13 ichpcib0 at pci0 dev 31 function 0 Intel 82801BA LPC rev 0x12 pciide0 at pci0 dev 31 function 1 Intel 82801BA IDE rev 0x12: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: ST380021A wd0: 16-sector PIO, LBA, 76319MB, 156301488 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: LITE-ON, LTR-52246S, 6S0F ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 uhci0 at pci0 dev 31 function 2 Intel 82801BA USB rev 0x12: apic 2 int 19 uhci1 at pci0 dev 31 function 4 Intel 82801BA USB rev 0x12: apic 2 int 23 auich0 at pci0 dev 31 function 5 Intel 82801BA AC97 rev 0x12: apic 2 int 17, ICH2 AC97 ac97: codec id 0x41445360 (Analog Devices AD1885) ac97: codec features headphone, Analog Devices Phat Stereo audio0 at auich0 isa0 at ichpcib0 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 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 10: GPIO VLM TMS gpio0 at nsclpcsio0: 29 pins npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 Intel UHCI root hub rev 1.00/1.00 addr 1 usb1 at uhci1: USB revision 1.0 uhub1 at usb1 Intel UHCI root hub rev 1.00/1.00 addr 1 mtrr: Pentium Pro MTRR
