hello
Hello,when I use ibus, I couldn't add chinese input method, so I can't type chinese in OpenBSD. But I can add chinese input method with FreeBSD and NetBSD. -- 谢谢
Re: panic at reboot - tsc_test_sync_ap
Hi Scott, all,
Thank you for the follow up.
I haven't tried this diff yet. (This routers support an application that
doesn't allow much downtime)
I'm planning on testing this whenever a new patch forces me to reboot.
Worst case on next version upgrade.
Best,
Pedro
A segunda, 9/01/2023, 16:26, Scott Cheloha
escreveu:
> Pedro,
>
> On Wed, Dec 14, 2022 at 12:24:42PM -0600, Scott Cheloha wrote:
> > On Wed, Dec 14, 2022 at 11:37:14AM +, Pedro Caetano wrote:
> > > Hi bugs@
> > >
> > > In the process of upgrading a pair of servers to release 7.2, the
> following
> > > panic was triggered after sysupgrade reboot. (dell poweredge R740)
> > >
> > > One of the reboots happened before syspatch, the other happened after
> > > applying the release patches.
> > >
> > > After powercycling, both servers managed to boot successfully.
> > >
> > > Please keep me copied as I'm not subscribed to bugs@
> > >
> > >
> > > Screenshot of the panic uploaded attached to this email.
> >
> > For reference:
> >
> > cpu2: 32KB 64B/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB
> 64b/line 16-way L2 cache, 8MB 64b/line 11-way L3 cache
> > cpu2: smt 0, core 5, package 0
> > panic: tsc_test_sync_ap: cpu2: tsc_ap_name is not NULL: cpu1
> > panic: tsc_test_sync_ap: cpu2: tsc_ap_name is not NULL: cpu1cpu3 at
> mainbus0: apid 26 (application process
> >
> > Somehow your machine is violating one of the TSC sync test sanity
> > checks. The idea behind this one is that there should only be one AP
> > in the sync test at a time.
> >
> > At the start of each test, in tsc_test_sync_ap(), the AP sets
> > tsc_ap_name to its dv_xname. It does this with an atomic CAS
> > expecting NULL to ensure no other AP is still running the sync test.
> > You're hitting this panic:
> >
> >449 void
> >450 tsc_test_sync_ap(struct cpu_info *ci)
> >451 {
> >452 if (!tsc_is_invariant)
> >453 return;
> >454 #ifndef TSC_DEBUG
> >455 if (!tsc_is_synchronized)
> >456 return;
> >457 #endif
> >458 /* The BP needs our name in order to report any
> problems. */
> >459 if (atomic_cas_ptr(_ap_name, NULL,
> ci->ci_dev->dv_xname) != NULL) {
> >460 panic("%s: %s: tsc_ap_name is not NULL: %s",
> >461 __func__, ci->ci_dev->dv_xname, tsc_ap_name);
> >462 }
> >
> > The BP is supposed to reset tsc_ap_name to NULL at the conclusion of
> > every sync test, from tsc_test_sync_bp():
> >
> >415 /*
> >416 * Report what happened. Adjust the TSC's
> quality
> >417 * if this is the first time we've failed the
> test.
> >418 */
> >419 tsc_report_test_results();
> >420 if (tsc_ap_status.lag_count ||
> tsc_bp_status.lag_count) {
> >421 if (tsc_is_synchronized) {
> >422 tsc_is_synchronized = 0;
> >423
> tc_reset_quality(_timecounter, -1000);
> >424 }
> >425 tsc_test_rounds = 0;
> >426 } else
> >427 tsc_test_rounds--;
> >428
> >429 /*
> >430 * Clean up for the next round. It is safe to
> reset the
> >431 * ingress barrier because at this point we know
> the AP
> >432 * has reached the egress barrier.
> >433 */
> >434 memset(_ap_status, 0, sizeof tsc_ap_status);
> >435 memset(_bp_status, 0, sizeof tsc_bp_status);
> >436 tsc_ingress_barrier = 0;
> >437 if (tsc_test_rounds == 0)
> >438 tsc_ap_name = NULL;
> >
> > It's possible the BP's store:
> >
> > tsc_ap_name = NULL;
> >
> > is not *always* globally visible by the time the next AP reaches the
> > tsc_ap_name CAS, triggering the panic. If so, we could force the
> > store to complete with membar_producer(). tsc_ap_name should be
> > volatile, too.
> >
> > OTOH, it's possible this particular check is not the right thing here.
> > My intention is correct... we definitely don't want more than one AP
> > in the sync test at any given moment. But this tsc_ap_name handshake
> > thing may be the wrong way to assert that.
>
> Just following up on this. Have you seen the panic you reported again?
>
Re: panic at reboot - tsc_test_sync_ap
Pedro,
On Wed, Dec 14, 2022 at 12:24:42PM -0600, Scott Cheloha wrote:
> On Wed, Dec 14, 2022 at 11:37:14AM +, Pedro Caetano wrote:
> > Hi bugs@
> >
> > In the process of upgrading a pair of servers to release 7.2, the following
> > panic was triggered after sysupgrade reboot. (dell poweredge R740)
> >
> > One of the reboots happened before syspatch, the other happened after
> > applying the release patches.
> >
> > After powercycling, both servers managed to boot successfully.
> >
> > Please keep me copied as I'm not subscribed to bugs@
> >
> >
> > Screenshot of the panic uploaded attached to this email.
>
> For reference:
>
> cpu2: 32KB 64B/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line
> 16-way L2 cache, 8MB 64b/line 11-way L3 cache
> cpu2: smt 0, core 5, package 0
> panic: tsc_test_sync_ap: cpu2: tsc_ap_name is not NULL: cpu1
> panic: tsc_test_sync_ap: cpu2: tsc_ap_name is not NULL: cpu1cpu3 at mainbus0:
> apid 26 (application process
>
> Somehow your machine is violating one of the TSC sync test sanity
> checks. The idea behind this one is that there should only be one AP
> in the sync test at a time.
>
> At the start of each test, in tsc_test_sync_ap(), the AP sets
> tsc_ap_name to its dv_xname. It does this with an atomic CAS
> expecting NULL to ensure no other AP is still running the sync test.
> You're hitting this panic:
>
>449 void
>450 tsc_test_sync_ap(struct cpu_info *ci)
>451 {
>452 if (!tsc_is_invariant)
>453 return;
>454 #ifndef TSC_DEBUG
>455 if (!tsc_is_synchronized)
>456 return;
>457 #endif
>458 /* The BP needs our name in order to report any problems. */
>459 if (atomic_cas_ptr(_ap_name, NULL, ci->ci_dev->dv_xname)
> != NULL) {
>460 panic("%s: %s: tsc_ap_name is not NULL: %s",
>461 __func__, ci->ci_dev->dv_xname, tsc_ap_name);
>462 }
>
> The BP is supposed to reset tsc_ap_name to NULL at the conclusion of
> every sync test, from tsc_test_sync_bp():
>
>415 /*
>416 * Report what happened. Adjust the TSC's quality
>417 * if this is the first time we've failed the test.
>418 */
>419 tsc_report_test_results();
>420 if (tsc_ap_status.lag_count ||
> tsc_bp_status.lag_count) {
>421 if (tsc_is_synchronized) {
>422 tsc_is_synchronized = 0;
>423 tc_reset_quality(_timecounter,
> -1000);
>424 }
>425 tsc_test_rounds = 0;
>426 } else
>427 tsc_test_rounds--;
>428
>429 /*
>430 * Clean up for the next round. It is safe to reset
> the
>431 * ingress barrier because at this point we know the
> AP
>432 * has reached the egress barrier.
>433 */
>434 memset(_ap_status, 0, sizeof tsc_ap_status);
>435 memset(_bp_status, 0, sizeof tsc_bp_status);
>436 tsc_ingress_barrier = 0;
>437 if (tsc_test_rounds == 0)
>438 tsc_ap_name = NULL;
>
> It's possible the BP's store:
>
> tsc_ap_name = NULL;
>
> is not *always* globally visible by the time the next AP reaches the
> tsc_ap_name CAS, triggering the panic. If so, we could force the
> store to complete with membar_producer(). tsc_ap_name should be
> volatile, too.
>
> OTOH, it's possible this particular check is not the right thing here.
> My intention is correct... we definitely don't want more than one AP
> in the sync test at any given moment. But this tsc_ap_name handshake
> thing may be the wrong way to assert that.
Just following up on this. Have you seen the panic you reported again?
Re: Kernel process drmwq spikes CPU usage
On 1/8/23 19:32, Jonathan Gray wrote: On Sat, Jan 07, 2023 at 09:46:17AM +, ba...@baak6.com wrote: Synopsis: Kernel process drmwq spikes CPU usage every 20 seconds on Protectcli Vault-2 Port hardware. Category: kernel Environment: System : OpenBSD 7.2 Details : OpenBSD 7.2 (GENERIC.MP) #4: Mon Dec 12 06:06:42 MST 2022 r...@syspatch-72-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 Description: I use this machine as a router. After upgrading to 7.2 I started getting pretty bad packet loss exactly every 20 seconds. After some investigation I noticed the drmwq kernel process using a lot of CPU every 20 seconds. When I plug a screen into the HDMI port on the machine, it stops spiking the CPU and the problem goes away. How-To-Repeat: Install OpenBSD 7.2 on a Protectcli Vault-2 port machine and observe kernel threads, the CPU will spike exactly every 20 seconds. This spike should cause packet loss that can be observed by running a ping. Fix: Plug a screen into the HDMI port of the machine. The screen does not have to be turned on. Try this. Diff against -current which has different drm code. Check your dmesg for the message after it occurs. no change in dmesg. Index: sys/dev/pci/drm/i915/display/intel_hotplug.c === RCS file: /cvs/src/sys/dev/pci/drm/i915/display/intel_hotplug.c,v retrieving revision 1.4 diff -u -p -r1.4 intel_hotplug.c --- sys/dev/pci/drm/i915/display/intel_hotplug.c1 Jan 2023 01:34:56 - 1.4 +++ sys/dev/pci/drm/i915/display/intel_hotplug.c9 Jan 2023 00:25:18 - @@ -194,7 +194,7 @@ intel_hpd_irq_storm_switch_to_polling(st dev_priv->display.hotplug.stats[pin].state != HPD_MARK_DISABLED) continue; - drm_info(_priv->drm, + drm_warn(_priv->drm, "HPD interrupt storm detected on connector %s: " "switching from hotplug detection to polling\n", connector->base.name);
Re: blank screen after fresh installation of 7.2 in powerpc
Yes, the console text shows when the machine is booting, with the background in blue, and it goes blank precisely after the following line is shown: [drm] *ERROR* Unable to locate a BIOS ROM No, I didn’t agree to xenom when installing. I just hit enter for the answer there was [no]. > Le 8 janv. 2023 à 21:08 , Jonathan Gray a écrit : > > On Sun, Jan 08, 2023 at 07:01:54PM -0500, Nuno Vasconcellos wrote: >>> Synopsis: blank screen after fresh installation >>> Category: powerpc >>> Environment: >> System : OpenBSD 7.2 >> Details : OpenBSD 7.2-stable (GENERIC) #1: Sun Jan 8 16:55:44 EST >> 2023 >> >> va...@urca.my.domain:/usr/src/sys/arch/macppc/compile/GENERIC >> >> Architecture: OpenBSD.macppc >> Machine : macppc >>> Description: >>After a fresh installation, the system booted with a blank screen. >>During the installation, it was noticed that fw_update installed >> radeondrm. >>Applicable patches installed. >>Release notes checked. >>No newer release found. >>Changes made between OpenBSD versions checked. >>Another reboot and still blank screen. >>Remote access via ssh from another machine. >>Logs in dmesg.boot and /var/log/Xorg.o.log check. >>In dmesg.boot log the following line caught my attention: >>[drm] *ERROR* Unable to locate a BIOS ROM >>In /var/log/Xorg.O.log file, the following lines also caught my >> attention: >>[42.182] (EE) AIGLX error: dlopen of >> /usr/X11R6/lib/modules/dri/r200_dri.so failed (File not found) >>[42.182] (EE) AIGLX error: unable to load driver r200 >>The command ls -l /usr/X11R6/lib/modules/dri/ was run and provided >> the following: >>total 128000 >>-r--r--r-- 4 root bin 16549188 Sep 29 15:02 kms_swrast_dri.so >>-r--r--r-- 4 root bin 16549188 Sep 29 15:02 r300_dri.so >>-r--r--r-- 4 root bin 16549188 Sep 29 15:02 r600_dri.so >>-r--r--r-- 4 root bin 16549188 Sep 29 15:02 swrast_dri.so >>Video card is ATI Radeon 9200 identified with pci bus 0:16:0 >>Machine is an Apple eMac PowerMac6,4 >>> How-To-Repeat: >>Install using cd72.iso for macppc and following instructions at the >> following link: >>https://ftp.openbsd.org/pub/OpenBSD/7.2/macppc/INSTALL.macppc >>> Fix: >>It seems that the fix is to provide the r200_dri.so file noted as not >> found in Xorg.O.log (radeondrm needs to be reviewed and updated?) >> > > The Mesa "classic" drivers, including r200_dri.so were removed from > upstream Mesa. Mesa falls back to software rendering. The old paths > are tried as there is a messy way to build them out of another Mesa > tree. OpenBSD does not include drivers from the amber tree of Mesa. > > Does the console text show when the machine is booting? Did you agree > to xenodm when installing? > >> SENDBUG: dmesg, pcidump, acpidump and usbdevs are attached. >> SENDBUG: Feel free to delete or use the -D flag if they contain sensitive >> information. >> >> dmesg: >> OpenBSD 7.2-stable (GENERIC) #1: Sun Jan 8 16:55:44 EST 2023 >>va...@urca.my.domain:/usr/src/sys/arch/macppc/compile/GENERIC >> real mem = 1073741824 (1024MB) >> avail mem = 1025462272 (977MB) >> random: good seed from bootblocks >> mpath0 at root >> scsibus0 at mpath0: 256 targets >> mainbus0 at root: model PowerMac6,4 >> cpu0 at mainbus0: 7447A (Revision 0x101): 1249 MHz: 512KB L2 cache >> mem0 at mainbus0 >> spdmem0 at mem0: 512MB DDR SDRAM non-parity PC3200CL2.5 >> spdmem1 at mem0: 512MB DDR SDRAM non-parity PC3200CL2.5 >> memc0 at mainbus0: uni-n rev 0xd2 >> "hw-clock" at memc0 not configured >> kiic0 at memc0 offset 0xf8001000 >> iic0 at kiic0 >> mpcpcibr0 at mainbus0 pci: uni-north >> pci0 at mpcpcibr0 bus 0 >> pchb0 at pci0 dev 11 function 0 "Apple UniNorth AGP" rev 0x00 >> agp at pchb0 not configured >> radeondrm0 at pci0 dev 16 function 0 "ATI Radeon 9200" rev 0x01 >> drm0 at radeondrm0 >> radeondrm0: irq 48 >> mpcpcibr1 at mainbus0 pci: uni-north >> pci1 at mpcpcibr1 bus 0 >> macobio0 at pci1 dev 23 function 0 "Apple Intrepid" rev 0x00 >> openpic0 at macobio0 offset 0x4: version 0x4614 feature 3f0302 LE >> macgpio0 at macobio0 offset 0x50 >> "modem-reset" at macgpio0 offset 0x1d not configured >> "modem-power" at macgpio0 offset 0x1c not configured >> macgpio1 at macgpio0 offset 0x9: irq 47 >> "programmer-switch" at macgpio0 offset 0x11 not configured >> "fan" at macgpio0 offset 0x0 not configured >> "gpio0" at macgpio0 offset 0x6a not configured >> "gpio5" at macgpio0 offset 0x6f not configured >> "gpio6" at macgpio0 offset 0x70 not configured >> "extint-gpio4" at macgpio0 offset 0x5c not configured >> "gpio11" at macgpio0 offset 0x75 not configured >> "extint-gpio15" at macgpio0 offset 0x67 not configured >> "escc-legacy" at macobio0 offset 0x12000 not configured >> zs0 at macobio0
uvideo0: can't allocate mmap buffer
On a new-ish Ryzen 7900X machine my USB webcam randomly fails to start (normally after 1 or 2 times of working, though it can sometimes fail to start even on the first attempt), leaving this in dmesg: uvideo0: can't allocate mmap buffer! Taking the device out and reinserting it doesn't fix the problem -- only a reboot allows it to work again. This card worked without any such issue on a Ryzen 9 machine and I must admit that I can't really guess what might have changed to cause mmap to fail in allocating a buffer. I'm attaching a dmesg with jsg's drm patches from this morning included (I've had exactly the same outcome with snapshots, including Friday(ish)'s for the last 2 or 3 weeks). Laurie OpenBSD 7.2-current (GENERIC.MP) #83: Mon Jan 9 07:58:57 GMT 2023 ltr...@overdrive.tratt.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 33390415872 (31843MB) avail mem = 32359079936 (30860MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.5 @ 0xa9b2b000 (43 entries) bios0: vendor American Megatrends International, LLC. version "1.40" date 11/23/2022 bios0: Micro-Star International Co., Ltd. MS-7D67 efi0 at bios0: UEFI 2.8 efi0: American Megatrends rev 0x5001a acpi0 at bios0: ACPI 6.4 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP IVRS SSDT SSDT FIDT MCFG HPET WDRT UEFI FPDT VFCT TPM2 SSDT CRAT CDIT BGRT SSDT SSDT SSDT SSDT WSMT APIC SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT acpi0: wakeup devices GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) GP17(S4) XHC0(S4) XHC1(S4) XHC2(S4) GPP0(S4) GPP1(S4) GPP2(S4) GPP7(S4) UP00(S4) DP00(S4) NV00(S4) DP20(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xf000, bus 0-127 acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 9 7900X 12-Core Processor, 4700.00 MHz, 19-61-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,L1DF,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 8-way L2 cache, 32MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 25MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: AMD Ryzen 9 7900X 12-Core Processor, 4700.00 MHz, 19-61-02 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,L1DF,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 8-way L2 cache, 32MB 64b/line 16-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: AMD Ryzen 9 7900X 12-Core Processor, 4700.00 MHz, 19-61-02 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,L1DF,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 8-way L2 cache, 32MB 64b/line 16-way L3 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: AMD Ryzen 9 7900X 12-Core Processor, 4700.00 MHz, 19-61-02 cpu3:
