Re: HDMI can't be used as primary monitor
On Wed, Feb 28, 2018 at 07:25:03AM +0100, Jiri Navratil wrote: > Thank you Mark for reply. > > I upraded to snapshot. Now the xrandr command shows properly HDMI > connected and possible modes, but the command > > xrandr --output eDP-1 --auto --rotate normal --pos 0x0 --output HDMI-1 --auto > --rotate normal --right-of eDP-1 > > it did not make HDMI TV to wakeup and I was not able to use it > > I see in dmesg this: > > uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 > addr 1 > error: [drm:pid86113:i915_gem_init_hw] *ERROR* Failed to initialize GuC, > error -8 (ignored) > uhub1 at uhub0 port 2 configuration 1 interface 0 "Generic 4-Port USB 2.0 > Hub" rev 2.10/1.17 addr 2 > WARNING !wm_changed failed at /usr/src/sys/dev/pci/drm/i915/intel_pm.c:3609 tl;dr but have you checked https://marc.info/?t=15169561314&r=1&w=2 ? Jiri
Re: VMD consumes 100% cpu after unpausing guest
* Dave Voutila [2018-02-27 21:29:25 -0500]: I can confirm this patch resolves the issue I reported. I _think_ I'm seeing a similar CPU load drop as well, but definitely have paused/unpaused the guest multiple times without issues. Thanks Dave and Peter for testing. I will commit this. I cannot explain a general decrease in CPU load because these lines are in the code path only when you unpause or receive a vm. * Peter Hessler [2018-02-27 11:16:52 +0100]: (btw, should rtc_fireper() receive a similar change?) rtc_fireper is unrelated to the cause of this. rtc_reschedule_per will do an event_add for rtc_fireper if required and rtc_fireper keeps on doing an event_add for itself. -- Pratik
Re: HDMI can't be used as primary monitor
Thank you Mark for reply. I upraded to snapshot. Now the xrandr command shows properly HDMI connected and possible modes, but the command xrandr --output eDP-1 --auto --rotate normal --pos 0x0 --output HDMI-1 --auto --rotate normal --right-of eDP-1 it did not make HDMI TV to wakeup and I was not able to use it I see in dmesg this: uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 error: [drm:pid86113:i915_gem_init_hw] *ERROR* Failed to initialize GuC, error -8 (ignored) uhub1 at uhub0 port 2 configuration 1 interface 0 "Generic 4-Port USB 2.0 Hub" rev 2.10/1.17 addr 2 WARNING !wm_changed failed at /usr/src/sys/dev/pci/drm/i915/intel_pm.c:3609 full dmesg is attached On Thu, Feb 22, 2018 at 11:03:44AM +0100, Mark Kettenis wrote: > > Date: Thu, 22 Feb 2018 07:50:57 +0100 (CET) > > From: j...@navratil.cz > > Please try a -current snapshot. -- Jiri Navratil, https://kouc.navratil.cz, +420 222 767 131 OpenBSD 6.2 (GENERIC.MP) #5: Fri Feb 2 23:02:19 CET 2018 r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8466038784 (8073MB) avail mem = 8202440704 (7822MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe0880 (61 entries) bios0: vendor LENOVO version "R0CET24W (1.12 )" date 05/06/2016 bios0: LENOVO 20GJ003QMC acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP TCPA SSDT UEFI SSDT SSDT HPET LPIT APIC MCFG SSDT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT BOOT BATB SLIC SSDT SSDT MSDM DMAR ASF! FPDT UEFI acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) GLAN(S4) XHC_(S4) XDCI(S4) HDAS(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(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-6200U CPU @ 2.30GHz, 2400.00 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 24 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2400.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2400.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2400.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus 1 (RP01) acpiprt5 at acpi0: bus -1 (RP02) acpiprt6 at acpi0: bus -1 (RP03) acpiprt7 at acpi0: bus 3 (RP04) acpiprt8 at acpi0: bus -1 (RP05) acpiprt9 at acpi0: bus -1 (RP06) acpiprt10 at acpi0: bus -1 (RP07) acpiprt11 at acpi0: bus -1 (RP08) acpiprt12 at acpi0: bus -1 (RP09) acpiprt13 at acpi0:
Re: VMD consumes 100% cpu after unpausing guest
Peter Hessler writes:
> On 2018 Feb 26 (Mon) at 18:52:34 -0800 (-0800), Pratik Vyas wrote:
> :* Dave Voutila [2018-02-22 23:40:21 -0500]:
> :
> :> > Synopsis:VMD consumes 100% cpu after unpausing guest
> :> > Category:amd64
> :> > Environment:
> :>System : OpenBSD 6.2
> :>Details : OpenBSD 6.2-current (GENERIC.MP) #10: Wed Feb 21 21:26:27
> MST 2018
> :>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> :>
> :>Architecture: OpenBSD.amd64
> :>Machine : amd64
> :>
> :> > Description:
> :>
> :>Not sure if this is a known issue, but I couldn't find anything
> :> searching the lists.
> :>
> :> Using an Alpine Linux guest vm, I can successfully pause the guest using
> :> `vmctl pause 1` and some time later resume it using `vmctl unpause 1`.
> :>
> :> Unpausing works as the guest comes back to life, I can SSH back in, and
> :> it's fine. However, on the host the vmd process representing that guest
> :> sits at 100% CPU utilization with 1 thread constantly queueing onto a
> :> cpu and running. The guest reports normal load so it must be one of the
> :> 2 threads.
> :
> :This should fix it.
> :
> :Use rtc_reschedule_per in mc146818_start instead of re arming the
> :periodic interrupt without checking if it's enabled in REGB.
> :
> :ok?
> :
> :--
> :Pratik
> :
> :Index: usr.sbin/vmd/mc146818.c
> :===
> :RCS file: /home/pdvyas/cvs/src/usr.sbin/vmd/mc146818.c,v
> :retrieving revision 1.15
> :diff -u -p -a -u -r1.15 mc146818.c
> :--- usr.sbin/vmd/mc146818.c 9 Jul 2017 00:51:40 - 1.15
> :+++ usr.sbin/vmd/mc146818.c 27 Feb 2018 02:47:18 -
> :@@ -354,6 +354,6 @@ mc146818_stop()
> :void
> :mc146818_start()
> :{
> :-evtimer_add(&rtc.per, &rtc.per_tv);
> : evtimer_add(&rtc.sec, &rtc.sec_tv);
> :+rtc_reschedule_per();
> :}
> :
>
> This helps a lot with the CPU load on a vmd host. Drops my single guest
> from ~50% CPU to ~9% CPU on the host.
I can confirm this patch resolves the issue I reported. I _think_ I'm
seeing a similar CPU load drop as well, but definitely have
paused/unpaused the guest multiple times without issues.
Re: panic: kernel diagnostic assertion "skrev->reverse == NULL"
On 2018-02-25 22:48, Johan Huldtgren wrote: On 2018-02-25 21:54, Alexander Bluhm wrote: On Sat, Feb 24, 2018 at 04:20:50PM -0500, Johan Huldtgren wrote: trying to connect to my gateway today I found the following panic. This is 100% reproducible anytime I connect via openvpn and then generate traffic. This first happened on the Feb 7th snap, I updated and it happens on the latest snap as well. The questions is what have you used before. I have rewritten the code at 2017/12/29. Was your working version before that? Looking back at my logs it looks like the last time I used it was January 20th, and the snap I had then was: OpenBSD 6.2-current (GENERIC) #316: Sat Dec 23 11:39:17 MST 2017 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC Although a bit different, a simmilar assertion was there before. ip_output(d2574200,0,f5275000,1,0,0,0) at ip_output+0x649 ip_forward(d2574200,d24b8000,d1f8aed8,0) at ip_forward+0x20a ddb> show mbuf mbuf 0xd05032f4 When you type "show mbuf" you must give the address of the mbuf. The functions ip_output() and ip_forward() pass it at the first argument. So "show mbuf 0xd2574200" would produces reasonable results, your command dumped arbitrary memory. thanks, noted for the future. panic: kernel diagnostic assertion "skrev->reverse == NULL" failed: file "/usr/src/sys/net/pf.c", line 7277 pf_find_state(d2486f00,f528d8e0,2,d251b900) at pf_find_state+0x28d This functions calls pf_state_key_link_reverse(sk, pkt_sk) with pkt_sk->reverse != NULL. On the way to that call we went through pkt_sk = m->m_pkthdr.pf.statekey; if (pkt_sk && pf_state_key_isvalid(pkt_sk->reverse)) sk = pkt_sk->reverse; We know that pkt_sk != NULL and pkt_sk->reverse != NULL and before doing the RB_FIND() lookup we check that sk == NULL. So pf_state_key_isvalid(pkt_sk->reverse) must be false. The kernel tried to use an invalid statekey. How can that happen? Invalid means sk->removed == 1, but pf_state_key_detach() also calls pf_state_key_unlink_reverse(). pf_test(2,3,d247d400,f528da64) at pf_test+0xb63 ip_output(d251b900,0,f528dad0,1,0,0,0) at ip_output+0x649 Here we find the outgoing state. The mbuf had a statekey before. ip_forward(d251b900,d247d400,d201cb48,0) at ip_forward+0x20a ip_input_if(f528dc64,f528dc50,4,0,d247d400) at ip_input_if+0x48e ipv4_input(d247d400,d251b900) at ipv4_input+0x2b Here pf attaches the incoming statekey to the mbuf. This is the one with the invalid reverse. tun_dev_write(d247d400,f528dd98,10001) at tun_dev_write+0x222 tunwrite(2800,f528dd98,11) at tunwrite+0x53 How does you pf config look like? Do you have some skip on tun? The only thing I have skip on is lo Was there unencrpyted traffic before you enabled openvpn? I assume so, this is my firewall there is always some traffic but tun0 is only used for openvpn Were there matching pf states before you enabled openvpn? I'm not sure exactly sure what you're asking, as this host does more than openvpn there would have been other states, not sure if I can find that now though? Does it immediately crash when you start openvpn and the first packet is sent out. It seems so I can connect and if I then (for example) ping a host on the inside, I get one (most I've ever seen is three) ping back and then nothing. At that point I can also see that the host has failed over to it's carp partner. Do you only use the tun interface and the outgoing interface? No, here is the output of ifconfig, there are several interfaces / vlans, # ifconfig lo0: flags=8049 mtu 32768 index 6 priority 0 llprio 3 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 inet 127.0.0.1 netmask 0xff00 vr0: flags=8b43 mtu 1500 lladdr 00:00:24:c9:58:4c index 1 priority 0 llprio 3 groups: egress media: Ethernet autoselect (100baseTX full-duplex) status: active inet 172.16.0.2 netmask 0xff00 broadcast 172.16.0.255 vr1: flags=8b43 mtu 1500 lladdr 00:00:24:c9:58:4d index 2 priority 0 llprio 3 media: Ethernet autoselect (100baseTX full-duplex) status: active vr2: flags=8b43 mtu 1500 lladdr 00:00:24:c9:58:4e index 3 priority 0 llprio 3 media: Ethernet autoselect (100baseTX full-duplex) status: active vr3: flags=8b43 mtu 1500 lladdr 00:00:24:c9:58:4f index 4 priority 0 llprio 3 media: Ethernet autoselect (100baseTX full-duplex) status: active enc0: flags=0<> index 5 priority 0 llprio 3 groups: enc status: active ral0: flags=8802 mtu 1500 lladdr 00:12:0e:61:7f:b0 index 7 priority 4 llprio 3 groups: wlan media: IEEE802.11 autoselect status: no network ieee80211: nwid "" carp0: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:01 index 8 priority 15 llprio 3
Re: uvideo0: could not open VS pipe: INVAL
-> 2018-02-26 Mon 17:02, Stefan Sperling, : > On Mon, Feb 26, 2018 at 04:09:36PM +0100, C. wrote: > > -> 2018-02-26 Mon 15:52, Martin Pieuchot, : > > > There's currently no support for isochronous transfers on xhci(4). Some > > > code is there but it has to be debugged and enabled. > > > > How can I help? :) > > Update to -current and check out sources. > Enable the isoch code in xhci.c (its entry point is under #if 0), > test your webcam (you will find that it won't work), and then > try to tweak xhci.c and uvideo.c until your webcam works. > > If those instructions don't help you, either spend more time on it > learning and hacking until you've reached the goal, or wait until > someone else fixes it. I am afraid hacking on this code myself is way out of my league yet. But I will try and test this code as soon as time allows to switch to -current. Thanks for the hints! -- [ Insert favourite quote here. ] signature.asc Description: PGP signature
Re: (Minor, in the unbound man pages, "SEE ALSO" refs don't hyperlink)
Hi,
Jason McIntyre wrote on Tue, Feb 27, 2018 at 07:07:04AM +:
> On Tue, Feb 27, 2018 at 02:01:30AM -0500, Tinker wrote:
>> The links in the unbound documentation
>> e.g. http://man.openbsd.org/unbound#SEE_ALSO
>> do not share format with the other OpenBSD docs
>> http://man.openbsd.org/cat#SEE_ALSO , so that the references
>> not are hyperlinks in the web version.
>> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/unbound/doc/
>> Normally OpenBSD man pages link by .Xr and the unbound man pages don't.
> you could petition the unbound project to convert their pages to mdoc
> format. better still, convert them yourself and submit those.
No, please don't.
Last time we talked to upstream (NLnet Labs) about this topic (in the
summer of 2014), they explicitly said they wanted to keep using man(7),
admittedly only citing weak reasons ("we don't need semantic markup
for these pages", which implies that they don't care about hyperlinks).
The rejection may also be motivated by using man(7) conistently for
all their projects including nsd(8), ldns, OpenDNSSEC, Net::DNS(3p),
and so on (though that's merely my guess).
So this is neither a technical question nor merely a question of doing
the work to modernize. It is a political question, and solving it
requires diplomacy and system integration / build system design skills.
Yours,
Ingo
Re: VMD consumes 100% cpu after unpausing guest
On 2018 Feb 26 (Mon) at 18:52:34 -0800 (-0800), Pratik Vyas wrote:
:* Dave Voutila [2018-02-22 23:40:21 -0500]:
:
:> > Synopsis: VMD consumes 100% cpu after unpausing guest
:> > Category: amd64
:> > Environment:
:> System : OpenBSD 6.2
:> Details : OpenBSD 6.2-current (GENERIC.MP) #10: Wed Feb 21 21:26:27
MST 2018
:>
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
:>
:> Architecture: OpenBSD.amd64
:> Machine : amd64
:>
:> > Description:
:>
:>Not sure if this is a known issue, but I couldn't find anything
:> searching the lists.
:>
:> Using an Alpine Linux guest vm, I can successfully pause the guest using
:> `vmctl pause 1` and some time later resume it using `vmctl unpause 1`.
:>
:> Unpausing works as the guest comes back to life, I can SSH back in, and
:> it's fine. However, on the host the vmd process representing that guest
:> sits at 100% CPU utilization with 1 thread constantly queueing onto a
:> cpu and running. The guest reports normal load so it must be one of the
:> 2 threads.
:
:This should fix it.
:
:Use rtc_reschedule_per in mc146818_start instead of re arming the
:periodic interrupt without checking if it's enabled in REGB.
:
:ok?
:
:--
:Pratik
:
:Index: usr.sbin/vmd/mc146818.c
:===
:RCS file: /home/pdvyas/cvs/src/usr.sbin/vmd/mc146818.c,v
:retrieving revision 1.15
:diff -u -p -a -u -r1.15 mc146818.c
:--- usr.sbin/vmd/mc146818.c9 Jul 2017 00:51:40 - 1.15
:+++ usr.sbin/vmd/mc146818.c27 Feb 2018 02:47:18 -
:@@ -354,6 +354,6 @@ mc146818_stop()
:void
:mc146818_start()
:{
:- evtimer_add(&rtc.per, &rtc.per_tv);
: evtimer_add(&rtc.sec, &rtc.sec_tv);
:+ rtc_reschedule_per();
:}
:
This helps a lot with the CPU load on a vmd host. Drops my single guest
from ~50% CPU to ~9% CPU on the host.
OK
(btw, should rtc_fireper() receive a similar change?)
--
The right half of the brain controls the left half of the body. This
means that only left handed people are in their right mind.
