Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink
5h later…
login: panic: assertwaitok: non-zero mutex count: 1
Stopped at db_enter+0x10: popq%rbp
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
db_enter() at db_enter+0x10
panic(81c882c4) at panic+0x128
assertwaitok() at assertwaitok+0xc7
mi_switch() at mi_switch+0x40
sleep_finish(8000225b8208,1) at sleep_finish+0x84
sleep_finish_all(8000225b8208,1) at sleep_finish_all+0x21
tsleep(800b1750,16,81c95c7d,33) at tsleep+0xd6
xhci_command_submit(8009c000,8000225b82f8,1dcd6500) at xhci_command
_submit+0x13f
xhci_abort_xfer(fd812e90c3c0,6) at xhci_abort_xfer+0x13a
usbd_abort_pipe(80bbe000) at usbd_abort_pipe+0x3d
cdce_stop(80bba800) at cdce_stop+0x46
cdce_encap(80bba800,fd80cf78c700,0) at cdce_encap+0xf7
cdce_start(80bba848) at cdce_start+0x84
if_qstart_compat(80bbaac0) at if_qstart_compat+0x2e
end trace frame: 0x8000225b8510, count: 0
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
> On 22 May 2020, at 21:05, Mark Kettenis wrote:
>
>> From: Łukasz Lejtkowski
>> Date: Fri, 22 May 2020 20:51:57 +0200
>>
>> Probably power supply 12 V is broken. Showing 16,87 V(Fluke 179) -
>> too high. Should be 12,25-12,50 V. I replaced to the new one.
>
> That might be why the device stops responding. The fact that cleaning
> up from a failed USB transaction leads to this panic is a bug though.
>
> And somebody just posted a very similar panic with ure(4). Something
> in the network stack is holding a mutex when it shouldn't.
>
>>> On 22 May 2020, at 20:05, Łukasz Lejtkowski wrote:
>>>
>>> 30 min ago… :/
>>>
>>>
>>> OpenBSD/amd64 (master.bsdxxx.xx) (tty00)
>>>
>>> login: panic: assertwaitok: non-zero mutex count: 1
>>> Stopped at db_enter+0x10: popq%rbp
>>> TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
>>> db_enter() at db_enter+0x10
>>> panic(81c882c4) at panic+0x128
>>> assertwaitok() at assertwaitok+0xc7
>>> mi_switch() at mi_switch+0x40
>>> sleep_finish(8000225b8538,1) at sleep_finish+0x84
>>> sleep_finish_all(8000225b8538,1) at sleep_finish_all+0x21
>>> tsleep(800b1750,16,81c95c7d,33) at tsleep+0xd6
>>> xhci_command_submit(8009c000,8000225b8628,1dcd6500) at
>>> xhci_command
>>> _submit+0x13f
>>> xhci_abort_xfer(fd812e90c780,6) at xhci_abort_xfer+0x13a
>>> usbd_abort_pipe(8047b000) at usbd_abort_pipe+0x3d
>>> cdce_stop(8012d000) at cdce_stop+0x46
>>> cdce_encap(8012d000,fd80c0731d00,0) at cdce_encap+0xf7
>>> cdce_start(8012d048) at cdce_start+0x84
>>> if_qstart_compat(8012d2c0) at if_qstart_compat+0x2e
>>> end trace frame: 0x8000225b8840, count: 0
>>> https://www.openbsd.org/ddb.html describes the minimum info required in bug
>>> reports. Insufficient info makes it difficult to find and fix bugs.
>>> ddb{2}>
>>>
On 22 May 2020, at 15:58, Łukasz Lejtkowski wrote:
Hi everyone,
After a few hours OpenBSD 6.7 crashes to ddb> . Without a LTE modem
OpenBSD 6.7 works stable. Huawei E3372s-153 HiLink on OpenBSD 6.6 works
perfectly, stable. Something wrong with USB, xHCI or cdce on OpenBSD 6.7
imho.
ddb{2}> show panic
assertwaitok: non-zero mutex count: 1
ddb{2}> trace
db_enter() at db_enter+0x10
panic(81c8ec25) at panic+0x128
assertwaitok() at assertwaitok+0xc7
mi_switch() at mi_switch+0x40
sleep_finish(8000225b8f88,1) at sleep_finish+0x84
sleep_finish_all(8000225b8f88,1) at sleep_finish_all+0x21
tsleep(800a5750,16,81c99248,33) at tsleep+0xd6
xhci_command_submit(8009,8000225b9078,1dcd6500) at
xhci_command
_submit+0x13f
xhci_abort_xfer(fd811e918690,6) at xhci_abort_xfer+0x13a
usbd_abort_pipe(8045f000) at usbd_abort_pipe+0x3d
cdce_stop(80119000) at cdce_stop+0x46
cdce_encap(80119000,fd80df8b8400,0) at cdce_encap+0xf7
cdce_start(80119048) at cdce_start+0x84
if_qstart_compat(801192c0) at if_qstart_compat+0x2e
ifq_serialize(801192c0,80119390) at ifq_serialize+0x103
taskq_thread(800290c0) at taskq_thread+0x4d
end trace frame: 0x0, count: -16
PC Engines apu2
coreboot build 20202604
BIOS version v4.11.0.6
4080 MB ECC DRAM
SeaBIOS (version rel-1.12.1.3-0-g300e8b70)
root@master[~]usbdevs -v
Controller /dev/usb0:
addr 01: 1022: AMD, xHCI root hub
super speed, self powered, config 1, rev 1.00
driver: uhub0
addr 02: 12d1:14dc HUAWEI_MOBILE, HUAWEI_MOBILE
high speed, self powered, config 1, rev 1.02
driver: cdce0
driver: umass0
Controller /dev/usb1:
addr 01: 1022: AMD, EHCI root hub
Re: BGPD route update loop between iBGP peers after 6.6->6.7 upgrade
And before anyone asks, I did check eBGP peers that networks in question did not repeatedly update and withdrew. Update messages between eBGP peers are nominal. Br -Esa On Sat, May 23, 2020 at 12:47 AM Esa Kuusisto wrote: > Hi > > I upgraded today two openbsd routers with openbgpd from 6.6 -> 6.7. > Upgrade was done using sysupgrade. Router1 and Router2 have two ebgp peers, > two iBGP peers to local switches and one iBGP peer between Router1 > <->Router2. Router2 was first upgraded and no problems there. After > Router1 upgrade I saw high cpu utilization from bgpd. From logs I saw that > both Router1 and Router2 saw two networks being updated between each other > and withdraw multiple times every second: > > May 23 00:20:24 Router1 bgpd[22905]: Rib Loc-RIB: neighbor AAA.BBB.211.252 > (PeerRouter2_v4) AS43XXX: withdraw 149.63.0.0/17 > May 23 00:20:24 Router1 bgpd[22905]: Rib Loc-RIB: neighbor AAA.BBB.211.252 > (PeerRouter2_v4) AS43XXX: withdraw 149.63.59.0/24 > May 23 00:20:24 Router1 bgpd[22905]: Rib Loc-RIB: neighbor AAA.BBB.211.252 > (PeerRouter2_v4) AS43XXX: update 149.63.0.0/17 via AAA.BBB.211.252 > May 23 00:20:24 Router1 bgpd[22905]: Rib Loc-RIB: neighbor AAA.BBB.211.252 > (PeerRouter2_v4) AS43XXX: update 149.63.59.0/24 via AAA.BBB.211.252 > > May 23 00:17:44 Router2 bgpd[17698]: Rib Loc-RIB: neighbor AAA.BBB.211.253 > (PeerRouter1_v4) AS43XXX: withdraw 149.63.0.0/17 > May 23 00:17:44 Router2 bgpd[17698]: Rib Loc-RIB: neighbor AAA.BBB.211.253 > (PeerRouter1_v4) AS43XXX: withdraw 149.63.59.0/24 > May 23 00:17:44 Router2 bgpd[17698]: Rib Loc-RIB: neighbor AAA.BBB.211.253 > (PeerRouter1_v4) AS43XXX: update 149.63.0.0/17 via AAA.BBB.211.253 > May 23 00:17:44 Router2 bgpd[17698]: Rib Loc-RIB: neighbor AAA.BBB.211.253 > (PeerRouter1_v4) AS43XXX: update 149.63.59.0/24 via AAA.BBB.211.253 > > Router1 > Neighbor ASMsgRcvdMsgSent OutQ Up/Down > State/PrfRcvd > PeerRouter2_v4 43XXX55646465639942 0 00:47:19 810647 > PeerRouter2_v6 43XXX 52294 82663 0 00:47:19 85391 > > Router2 > Neighbor ASMsgRcvdMsgSent OutQ Up/Down > State/PrfRcvd > PeerRouter1_v4 43XXX60393646037168 0 00:47:34 810654 > PeerRouter1_v6 43XXX 421226 417520 0 00:47:34 87247 > > I do not have any relation to those 149.63/17 and 149.63.59/24 networks. > > For debug purposes I did filter those announcements and problem was fixed. > I did remove filter to test if the announcement loop was gone and it was > for now. > No configuration changes to bgpd.conf before or after upgrade (except that > filter after the high cpu load reason was found). > > Br > -Esa Kuusisto > > dmesg: > OpenBSD 6.7 (RAMDISK_CD) #177: Thu May 7 11:19:02 MDT 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD > real mem = 4278124544 (4079MB) > avail mem = 417488 (3952MB) > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (242 entries) > bios0: vendor Phoenix Technologies LTD version "6.00" date 09/19/2018 > bios0: VMware, Inc. VMware Virtual Platform > acpi0 at bios0: ACPI 4.0 > acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz, 2799.91 MHz, 06-3a-00 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: apic clock running at 65MHz > cpu at mainbus0: not configured > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins > acpiprt0 at acpi0: bus 0 (PCI0) > acpicpu at acpi0 not configured > "PNP0A03" at acpi0 not configured > acpicmos0 at acpi0 > "PNP0A05" at acpi0 not configured > "ACPI0003" at acpi0 not configured > cpu0: using IvyBridge MDS workaround > pvbus0 at mainbus0: VMware > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01 > ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01 > pci1 at ppb0 bus 1 > "Intel 82371AB PIIX4 ISA" rev 0x08 at pci0 dev 7 function 0 not configured > pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, > channel 0 configured to compatibility, channel 1 configured to compatibility > pciide0: channel 0 disabled (no drives) > atapiscsi0 at pciide0 channel 1 drive 0 > scsibus0 at atapiscsi0: 2 targets > cd0 at scsibus0 targ 0 lun 0: removable > cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 > "Intel 82371AB Power" rev 0x08 at pci0 dev 7 function 3 not configured > "VMware VMCI" rev 0x10 at pci0 dev 7 function 7 not configured > vga1 at pci0 dev 15 function 0 "VMware SVGA II" rev 0x00 > vga1: aperture needed > wsdisplay1 at vga1 mux 1:
BGPD route update loop between iBGP peers after 6.6->6.7 upgrade
Hi I upgraded today two openbsd routers with openbgpd from 6.6 -> 6.7. Upgrade was done using sysupgrade. Router1 and Router2 have two ebgp peers, two iBGP peers to local switches and one iBGP peer between Router1 <->Router2. Router2 was first upgraded and no problems there. After Router1 upgrade I saw high cpu utilization from bgpd. From logs I saw that both Router1 and Router2 saw two networks being updated between each other and withdraw multiple times every second: May 23 00:20:24 Router1 bgpd[22905]: Rib Loc-RIB: neighbor AAA.BBB.211.252 (PeerRouter2_v4) AS43XXX: withdraw 149.63.0.0/17 May 23 00:20:24 Router1 bgpd[22905]: Rib Loc-RIB: neighbor AAA.BBB.211.252 (PeerRouter2_v4) AS43XXX: withdraw 149.63.59.0/24 May 23 00:20:24 Router1 bgpd[22905]: Rib Loc-RIB: neighbor AAA.BBB.211.252 (PeerRouter2_v4) AS43XXX: update 149.63.0.0/17 via AAA.BBB.211.252 May 23 00:20:24 Router1 bgpd[22905]: Rib Loc-RIB: neighbor AAA.BBB.211.252 (PeerRouter2_v4) AS43XXX: update 149.63.59.0/24 via AAA.BBB.211.252 May 23 00:17:44 Router2 bgpd[17698]: Rib Loc-RIB: neighbor AAA.BBB.211.253 (PeerRouter1_v4) AS43XXX: withdraw 149.63.0.0/17 May 23 00:17:44 Router2 bgpd[17698]: Rib Loc-RIB: neighbor AAA.BBB.211.253 (PeerRouter1_v4) AS43XXX: withdraw 149.63.59.0/24 May 23 00:17:44 Router2 bgpd[17698]: Rib Loc-RIB: neighbor AAA.BBB.211.253 (PeerRouter1_v4) AS43XXX: update 149.63.0.0/17 via AAA.BBB.211.253 May 23 00:17:44 Router2 bgpd[17698]: Rib Loc-RIB: neighbor AAA.BBB.211.253 (PeerRouter1_v4) AS43XXX: update 149.63.59.0/24 via AAA.BBB.211.253 Router1 Neighbor ASMsgRcvdMsgSent OutQ Up/Down State/PrfRcvd PeerRouter2_v4 43XXX55646465639942 0 00:47:19 810647 PeerRouter2_v6 43XXX 52294 82663 0 00:47:19 85391 Router2 Neighbor ASMsgRcvdMsgSent OutQ Up/Down State/PrfRcvd PeerRouter1_v4 43XXX60393646037168 0 00:47:34 810654 PeerRouter1_v6 43XXX 421226 417520 0 00:47:34 87247 I do not have any relation to those 149.63/17 and 149.63.59/24 networks. For debug purposes I did filter those announcements and problem was fixed. I did remove filter to test if the announcement loop was gone and it was for now. No configuration changes to bgpd.conf before or after upgrade (except that filter after the high cpu load reason was found). Br -Esa Kuusisto dmesg: OpenBSD 6.7 (RAMDISK_CD) #177: Thu May 7 11:19:02 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 4278124544 (4079MB) avail mem = 417488 (3952MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (242 entries) bios0: vendor Phoenix Technologies LTD version "6.00" date 09/19/2018 bios0: VMware, Inc. VMware Virtual Platform acpi0 at bios0: ACPI 4.0 acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz, 2799.91 MHz, 06-3a-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 65MHz cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpicpu at acpi0 not configured "PNP0A03" at acpi0 not configured acpicmos0 at acpi0 "PNP0A05" at acpi0 not configured "ACPI0003" at acpi0 not configured cpu0: using IvyBridge MDS workaround pvbus0 at mainbus0: VMware pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01 ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01 pci1 at ppb0 bus 1 "Intel 82371AB PIIX4 ISA" rev 0x08 at pci0 dev 7 function 0 not configured pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 disabled (no drives) atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 "Intel 82371AB Power" rev 0x08 at pci0 dev 7 function 3 not configured "VMware VMCI" rev 0x10 at pci0 dev 7 function 7 not configured vga1 at pci0 dev 15 function 0 "VMware SVGA II" rev 0x00 vga1: aperture needed wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) mpi0 at pci0 dev 16 function 0 "Symbios Logic 53c1030" rev 0x01: apic 2 int 17 mpi0: 0, firmware 1.3.41.32 scsibus1 at mpi0: 16 targets, initiator 7 sd0 at scsibus1 targ 0 lun 0: sd0: 8192MB, 512 bytes/sector, 16777216 sectors, thin mpi0: target 0 Sync at 160MHz width 16bit offset 127 QAS 1 DT 1 IU 1 ppb1 at pci0 dev 17 function 0 "VMware PCI" rev 0x02 pci2 at ppb1 bus 2 ppb2 at
Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink
> From: Łukasz Lejtkowski
> Date: Fri, 22 May 2020 20:51:57 +0200
>
> Probably power supply 12 V is broken. Showing 16,87 V(Fluke 179) -
> too high. Should be 12,25-12,50 V. I replaced to the new one.
That might be why the device stops responding. The fact that cleaning
up from a failed USB transaction leads to this panic is a bug though.
And somebody just posted a very similar panic with ure(4). Something
in the network stack is holding a mutex when it shouldn't.
> > On 22 May 2020, at 20:05, Łukasz Lejtkowski wrote:
> >
> > 30 min ago… :/
> >
> >
> > OpenBSD/amd64 (master.bsdxxx.xx) (tty00)
> >
> > login: panic: assertwaitok: non-zero mutex count: 1
> > Stopped at db_enter+0x10: popq%rbp
> >TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
> > db_enter() at db_enter+0x10
> > panic(81c882c4) at panic+0x128
> > assertwaitok() at assertwaitok+0xc7
> > mi_switch() at mi_switch+0x40
> > sleep_finish(8000225b8538,1) at sleep_finish+0x84
> > sleep_finish_all(8000225b8538,1) at sleep_finish_all+0x21
> > tsleep(800b1750,16,81c95c7d,33) at tsleep+0xd6
> > xhci_command_submit(8009c000,8000225b8628,1dcd6500) at
> > xhci_command
> > _submit+0x13f
> > xhci_abort_xfer(fd812e90c780,6) at xhci_abort_xfer+0x13a
> > usbd_abort_pipe(8047b000) at usbd_abort_pipe+0x3d
> > cdce_stop(8012d000) at cdce_stop+0x46
> > cdce_encap(8012d000,fd80c0731d00,0) at cdce_encap+0xf7
> > cdce_start(8012d048) at cdce_start+0x84
> > if_qstart_compat(8012d2c0) at if_qstart_compat+0x2e
> > end trace frame: 0x8000225b8840, count: 0
> > https://www.openbsd.org/ddb.html describes the minimum info required in bug
> > reports. Insufficient info makes it difficult to find and fix bugs.
> > ddb{2}>
> >
> >> On 22 May 2020, at 15:58, Łukasz Lejtkowski wrote:
> >>
> >> Hi everyone,
> >>
> >> After a few hours OpenBSD 6.7 crashes to ddb> . Without a LTE modem
> >> OpenBSD 6.7 works stable. Huawei E3372s-153 HiLink on OpenBSD 6.6 works
> >> perfectly, stable. Something wrong with USB, xHCI or cdce on OpenBSD 6.7
> >> imho.
> >>
> >> ddb{2}> show panic
> >> assertwaitok: non-zero mutex count: 1
> >>
> >> ddb{2}> trace
> >> db_enter() at db_enter+0x10
> >> panic(81c8ec25) at panic+0x128
> >> assertwaitok() at assertwaitok+0xc7
> >> mi_switch() at mi_switch+0x40
> >> sleep_finish(8000225b8f88,1) at sleep_finish+0x84
> >> sleep_finish_all(8000225b8f88,1) at sleep_finish_all+0x21
> >> tsleep(800a5750,16,81c99248,33) at tsleep+0xd6
> >> xhci_command_submit(8009,8000225b9078,1dcd6500) at
> >> xhci_command
> >> _submit+0x13f
> >> xhci_abort_xfer(fd811e918690,6) at xhci_abort_xfer+0x13a
> >> usbd_abort_pipe(8045f000) at usbd_abort_pipe+0x3d
> >> cdce_stop(80119000) at cdce_stop+0x46
> >> cdce_encap(80119000,fd80df8b8400,0) at cdce_encap+0xf7
> >> cdce_start(80119048) at cdce_start+0x84
> >> if_qstart_compat(801192c0) at if_qstart_compat+0x2e
> >> ifq_serialize(801192c0,80119390) at ifq_serialize+0x103
> >> taskq_thread(800290c0) at taskq_thread+0x4d
> >> end trace frame: 0x0, count: -16
> >>
> >>
> >>
> >> PC Engines apu2
> >> coreboot build 20202604
> >> BIOS version v4.11.0.6
> >> 4080 MB ECC DRAM
> >> SeaBIOS (version rel-1.12.1.3-0-g300e8b70)
> >>
> >>
> >> root@master[~]usbdevs -v
> >> Controller /dev/usb0:
> >> addr 01: 1022: AMD, xHCI root hub
> >> super speed, self powered, config 1, rev 1.00
> >> driver: uhub0
> >> addr 02: 12d1:14dc HUAWEI_MOBILE, HUAWEI_MOBILE
> >> high speed, self powered, config 1, rev 1.02
> >> driver: cdce0
> >> driver: umass0
> >> Controller /dev/usb1:
> >> addr 01: 1022: AMD, EHCI root hub
> >> high speed, self powered, config 1, rev 1.00
> >> driver: uhub1
> >> addr 02: 0438:7900 Advanced Micro Devices, Hub
> >> high speed, self powered, config 1, rev 0.18
> >> driver: uhub2
> >>
> >>
> >> root@master[~]usbdevs -vv
> >> Controller /dev/usb0:
> >> addr 01: 1022: AMD, xHCI root hub
> >> super speed, self powered, config 1, rev 1.00
> >> driver: uhub0
> >> port 01: .02a0 power Rx.detect
> >> port 02: .02a0 power Rx.detect
> >> port 03: .0503 connect enabled recovery
> >> port 04: .02a0 power Rx.detect
> >> addr 02: 12d1:14dc HUAWEI_MOBILE, HUAWEI_MOBILE
> >> high speed, self powered, config 1, rev 1.02
> >> driver: cdce0
> >> driver: umass0
> >> Controller /dev/usb1:
> >> addr 01: 1022: AMD, EHCI root hub
> >> high speed, self powered, config 1, rev 1.00
> >> driver: uhub1
> >> port 01: .0503 connect enabled power
> >> port 02: .0500 power
> >> addr 02: 0438:7900 Advanced Micro Devices, Hub
> >> high speed, self powered, config 1, rev 0.18
> >> driver: uhub2
> >> port 01: .0100 power
> >> port 02: .0100 power
> >> port
Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink
Probably power supply 12 V is broken. Showing 16,87 V(Fluke 179) - too high.
Should be 12,25-12,50 V. I replaced to the new one.
> On 22 May 2020, at 20:05, Łukasz Lejtkowski wrote:
>
> 30 min ago… :/
>
>
> OpenBSD/amd64 (master.bsdxxx.xx) (tty00)
>
> login: panic: assertwaitok: non-zero mutex count: 1
> Stopped at db_enter+0x10: popq%rbp
>TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
> db_enter() at db_enter+0x10
> panic(81c882c4) at panic+0x128
> assertwaitok() at assertwaitok+0xc7
> mi_switch() at mi_switch+0x40
> sleep_finish(8000225b8538,1) at sleep_finish+0x84
> sleep_finish_all(8000225b8538,1) at sleep_finish_all+0x21
> tsleep(800b1750,16,81c95c7d,33) at tsleep+0xd6
> xhci_command_submit(8009c000,8000225b8628,1dcd6500) at
> xhci_command
> _submit+0x13f
> xhci_abort_xfer(fd812e90c780,6) at xhci_abort_xfer+0x13a
> usbd_abort_pipe(8047b000) at usbd_abort_pipe+0x3d
> cdce_stop(8012d000) at cdce_stop+0x46
> cdce_encap(8012d000,fd80c0731d00,0) at cdce_encap+0xf7
> cdce_start(8012d048) at cdce_start+0x84
> if_qstart_compat(8012d2c0) at if_qstart_compat+0x2e
> end trace frame: 0x8000225b8840, count: 0
> https://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports. Insufficient info makes it difficult to find and fix bugs.
> ddb{2}>
>
>> On 22 May 2020, at 15:58, Łukasz Lejtkowski wrote:
>>
>> Hi everyone,
>>
>> After a few hours OpenBSD 6.7 crashes to ddb> . Without a LTE modem OpenBSD
>> 6.7 works stable. Huawei E3372s-153 HiLink on OpenBSD 6.6 works perfectly,
>> stable. Something wrong with USB, xHCI or cdce on OpenBSD 6.7 imho.
>>
>> ddb{2}> show panic
>> assertwaitok: non-zero mutex count: 1
>>
>> ddb{2}> trace
>> db_enter() at db_enter+0x10
>> panic(81c8ec25) at panic+0x128
>> assertwaitok() at assertwaitok+0xc7
>> mi_switch() at mi_switch+0x40
>> sleep_finish(8000225b8f88,1) at sleep_finish+0x84
>> sleep_finish_all(8000225b8f88,1) at sleep_finish_all+0x21
>> tsleep(800a5750,16,81c99248,33) at tsleep+0xd6
>> xhci_command_submit(8009,8000225b9078,1dcd6500) at
>> xhci_command
>> _submit+0x13f
>> xhci_abort_xfer(fd811e918690,6) at xhci_abort_xfer+0x13a
>> usbd_abort_pipe(8045f000) at usbd_abort_pipe+0x3d
>> cdce_stop(80119000) at cdce_stop+0x46
>> cdce_encap(80119000,fd80df8b8400,0) at cdce_encap+0xf7
>> cdce_start(80119048) at cdce_start+0x84
>> if_qstart_compat(801192c0) at if_qstart_compat+0x2e
>> ifq_serialize(801192c0,80119390) at ifq_serialize+0x103
>> taskq_thread(800290c0) at taskq_thread+0x4d
>> end trace frame: 0x0, count: -16
>>
>>
>>
>> PC Engines apu2
>> coreboot build 20202604
>> BIOS version v4.11.0.6
>> 4080 MB ECC DRAM
>> SeaBIOS (version rel-1.12.1.3-0-g300e8b70)
>>
>>
>> root@master[~]usbdevs -v
>> Controller /dev/usb0:
>> addr 01: 1022: AMD, xHCI root hub
>> super speed, self powered, config 1, rev 1.00
>> driver: uhub0
>> addr 02: 12d1:14dc HUAWEI_MOBILE, HUAWEI_MOBILE
>> high speed, self powered, config 1, rev 1.02
>> driver: cdce0
>> driver: umass0
>> Controller /dev/usb1:
>> addr 01: 1022: AMD, EHCI root hub
>> high speed, self powered, config 1, rev 1.00
>> driver: uhub1
>> addr 02: 0438:7900 Advanced Micro Devices, Hub
>> high speed, self powered, config 1, rev 0.18
>> driver: uhub2
>>
>>
>> root@master[~]usbdevs -vv
>> Controller /dev/usb0:
>> addr 01: 1022: AMD, xHCI root hub
>> super speed, self powered, config 1, rev 1.00
>> driver: uhub0
>> port 01: .02a0 power Rx.detect
>> port 02: .02a0 power Rx.detect
>> port 03: .0503 connect enabled recovery
>> port 04: .02a0 power Rx.detect
>> addr 02: 12d1:14dc HUAWEI_MOBILE, HUAWEI_MOBILE
>> high speed, self powered, config 1, rev 1.02
>> driver: cdce0
>> driver: umass0
>> Controller /dev/usb1:
>> addr 01: 1022: AMD, EHCI root hub
>> high speed, self powered, config 1, rev 1.00
>> driver: uhub1
>> port 01: .0503 connect enabled power
>> port 02: .0500 power
>> addr 02: 0438:7900 Advanced Micro Devices, Hub
>> high speed, self powered, config 1, rev 0.18
>> driver: uhub2
>> port 01: .0100 power
>> port 02: .0100 power
>> port 03: .0100 power
>> port 04: .0100 power
>>
>>
>> root@master[~]ifconfig cdce0
>> cdce0: flags=8843 mtu 1500
>> lladdr xx:xx:xx:xx:xx:xx
>> index 6 priority 0 llprio 3
>> inet 192.168.8.100 netmask 0xff00 broadcast 192.168.8.255
>>
>>
>>
>>
>> root@master[~]dmesg
>> OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020
>>
>> r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> real mem = 4259880960 (4062MB)
>> avail mem = 4118163456 (3927MB)
>>
Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink
30 min ago… :/
OpenBSD/amd64 (master.bsdxxx.xx) (tty00)
login: panic: assertwaitok: non-zero mutex count: 1
Stopped at db_enter+0x10: popq%rbp
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
db_enter() at db_enter+0x10
panic(81c882c4) at panic+0x128
assertwaitok() at assertwaitok+0xc7
mi_switch() at mi_switch+0x40
sleep_finish(8000225b8538,1) at sleep_finish+0x84
sleep_finish_all(8000225b8538,1) at sleep_finish_all+0x21
tsleep(800b1750,16,81c95c7d,33) at tsleep+0xd6
xhci_command_submit(8009c000,8000225b8628,1dcd6500) at xhci_command
_submit+0x13f
xhci_abort_xfer(fd812e90c780,6) at xhci_abort_xfer+0x13a
usbd_abort_pipe(8047b000) at usbd_abort_pipe+0x3d
cdce_stop(8012d000) at cdce_stop+0x46
cdce_encap(8012d000,fd80c0731d00,0) at cdce_encap+0xf7
cdce_start(8012d048) at cdce_start+0x84
if_qstart_compat(8012d2c0) at if_qstart_compat+0x2e
end trace frame: 0x8000225b8840, count: 0
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{2}>
> On 22 May 2020, at 15:58, Łukasz Lejtkowski wrote:
>
> Hi everyone,
>
> After a few hours OpenBSD 6.7 crashes to ddb> . Without a LTE modem OpenBSD
> 6.7 works stable. Huawei E3372s-153 HiLink on OpenBSD 6.6 works perfectly,
> stable. Something wrong with USB, xHCI or cdce on OpenBSD 6.7 imho.
>
> ddb{2}> show panic
> assertwaitok: non-zero mutex count: 1
>
> ddb{2}> trace
> db_enter() at db_enter+0x10
> panic(81c8ec25) at panic+0x128
> assertwaitok() at assertwaitok+0xc7
> mi_switch() at mi_switch+0x40
> sleep_finish(8000225b8f88,1) at sleep_finish+0x84
> sleep_finish_all(8000225b8f88,1) at sleep_finish_all+0x21
> tsleep(800a5750,16,81c99248,33) at tsleep+0xd6
> xhci_command_submit(8009,8000225b9078,1dcd6500) at
> xhci_command
> _submit+0x13f
> xhci_abort_xfer(fd811e918690,6) at xhci_abort_xfer+0x13a
> usbd_abort_pipe(8045f000) at usbd_abort_pipe+0x3d
> cdce_stop(80119000) at cdce_stop+0x46
> cdce_encap(80119000,fd80df8b8400,0) at cdce_encap+0xf7
> cdce_start(80119048) at cdce_start+0x84
> if_qstart_compat(801192c0) at if_qstart_compat+0x2e
> ifq_serialize(801192c0,80119390) at ifq_serialize+0x103
> taskq_thread(800290c0) at taskq_thread+0x4d
> end trace frame: 0x0, count: -16
>
>
>
> PC Engines apu2
> coreboot build 20202604
> BIOS version v4.11.0.6
> 4080 MB ECC DRAM
> SeaBIOS (version rel-1.12.1.3-0-g300e8b70)
>
>
> root@master[~]usbdevs -v
> Controller /dev/usb0:
> addr 01: 1022: AMD, xHCI root hub
>super speed, self powered, config 1, rev 1.00
>driver: uhub0
> addr 02: 12d1:14dc HUAWEI_MOBILE, HUAWEI_MOBILE
>high speed, self powered, config 1, rev 1.02
>driver: cdce0
>driver: umass0
> Controller /dev/usb1:
> addr 01: 1022: AMD, EHCI root hub
>high speed, self powered, config 1, rev 1.00
>driver: uhub1
> addr 02: 0438:7900 Advanced Micro Devices, Hub
>high speed, self powered, config 1, rev 0.18
>driver: uhub2
>
>
> root@master[~]usbdevs -vv
> Controller /dev/usb0:
> addr 01: 1022: AMD, xHCI root hub
>super speed, self powered, config 1, rev 1.00
>driver: uhub0
>port 01: .02a0 power Rx.detect
>port 02: .02a0 power Rx.detect
>port 03: .0503 connect enabled recovery
>port 04: .02a0 power Rx.detect
> addr 02: 12d1:14dc HUAWEI_MOBILE, HUAWEI_MOBILE
>high speed, self powered, config 1, rev 1.02
>driver: cdce0
>driver: umass0
> Controller /dev/usb1:
> addr 01: 1022: AMD, EHCI root hub
>high speed, self powered, config 1, rev 1.00
>driver: uhub1
>port 01: .0503 connect enabled power
>port 02: .0500 power
> addr 02: 0438:7900 Advanced Micro Devices, Hub
>high speed, self powered, config 1, rev 0.18
>driver: uhub2
>port 01: .0100 power
>port 02: .0100 power
>port 03: .0100 power
>port 04: .0100 power
>
>
> root@master[~]ifconfig cdce0
> cdce0: flags=8843 mtu 1500
> lladdr xx:xx:xx:xx:xx:xx
> index 6 priority 0 llprio 3
> inet 192.168.8.100 netmask 0xff00 broadcast 192.168.8.255
>
>
>
>
> root@master[~]dmesg
> OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020
>
> r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4259880960 (4062MB)
> avail mem = 4118163456 (3927MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xcfe8d020 (13 entries)
> bios0: vendor coreboot version "v4.11.0.6" date 04/26/2020
> bios0: PC Engines apu2
> acpi0 at bios0: ACPI 6.0
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP SSDT MCFG TPM2
Re: athn(4): AR9287 instability
On Thu, May 21, 2020 at 9:11 AM Stefan Sperling wrote: > On Thu, May 21, 2020 at 01:04:36AM +0200, stolen data wrote: > > ... > > > > You can try MCS1, MCS2, ..., all the way up to MCS15. > > > > Unfortunately no change. Some are unusable but none of them offer a > > visible improvement. > > Oh. So they all have the exact same result? > None of MCS0-15 can reach beyond 1200 Kbit/s and some are exceptionally unstable; 5-7 and 13-15 (with emphasis on 7 and 15) are so shaky that the speed drops below 50 Kbit/s and sometimes cause the entire link to choke and drop out. Across the range it seems to be best at 0/8 and degrade towards 7/15. I can't see any difference between the lower and upper range, and autoselect overall seems to work out better over time despite still being very jumpy. > > > I'll be available for testing of any patches or suggestions that > > anyone may have, and thanks for the suggestions so far! > > What is special about the AR9287 is that it appears in USB devices > as well as PCI. > > The USB devices are known to work OK (barring some USB-specific issues). > However, the firmware on USB devices handles large parts of what our driver > is supposed to handle on PCI, so it's another apples to oranges comparison. > > The next step would be to grep the Linux and OpenBSD drivers for 9287 > and compare chip-specific sections of code that show up. I looked around > for a bit but nothing stands out at first sight. >
Re: cannot clean-install KVM/QEMU VM that don't support MSR_TSX_CTRL
Reading that diff, I get a sense they pass on underlying-hardware cpu flags as-is, and then only write the support code when they feel like it. If so, that is ridiculous. They should immediately mask against a list of KNOWN and CURRENTLY SUPPORTED bits, and not pass on unknown stuff. SASANO Takayoshi wrote: > > 1) Broken emulator > > 2) Old broken emulator > > > > A real cpu behaves that way. The capability bits says the feature > > exists, and when it exists, it MUST work. > > Yes, I think KVM/QEMU may be malfunction and I found a patch for > QEMU that supports MSR_TSX_CTRL. > > https://www.mail-archive.com/qemu-devel@nongnu.org/msg660546.html > > > Have you have filed a bug with the authors of the emulator? > > So I didn't write any bug report to them. > > > If newer code emulators have it fixed, then again, how is this our > > fault for using the feature as advertised in all real hardware? > > It may be no problem that running KVM/QEMU locally (simply install new > emulator by myself), but I found this MSR_TSX_CTRL problem on VPS service. > > I understand that I have to consult support desk of the service provider and > ask them to update QEMU. > > Regards, > -- > SASANO Takayoshi (JG1UAA)
Re: USB ure RTL8153 panics on release 6.7 + 001_wscons
> On May 21, 2020, at 7:04 PM, Jonathon Fletcher
> wrote:
>
>
>> On May 21, 2020, at 12:39 AM, Kevin Lo wrote:
>>
>> On Tue, May 19, 2020 at 09:52:57AM -0700, Jonathon Fletcher wrote:
>>>
>>>
Synopsis: ure RTL8153 panics on 6.7 - was stable on 6.6
>>>
Environment:
>>> System : OpenBSD 6.7
>>> Details : OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020
>>>
>>> r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>>>
>>> Architecture: OpenBSD.amd64
>>> Machine : amd64
>>>
Description:
>>> ** PRELIMINARY BUG REPORT - INCOMPLETE INFO **
>>>
>>> USB ure with RTL8153 on 6.7 panics. Same hardware stable on 6.6.
>>>
>>> ure0 at uhub0 port 14 configuration 1 interface 0 "Realtek USB 10/100/1000
>>> LAN" rev 3.00/30.00 addr 5
>>> ure0: RTL8153 (0x5c30), address a0:ce:c8:cd:ba:d1
>>> rgephy0 at ure0 phy 0: RTL8251 PHY, rev. 0
>>>
>>> Under load (estimated 50MB/s for approximate 5 minutes), kernel panics:
>
> ...
>
>>> Aside:
>>>
>>> Same panic occurred with RTL8156 - first 6.7 panic. After that I reverted
>>> to the RTL8153 above in case panic was limited to the newly-supported
>>> hardware.
>>>
>>> ure0 at uhub0 port 14 configuration 1 interface 0 "Realtek USB
>>> 10/100/1G/2.5G LAN" rev 3.20/30.00 addr 5
>>> ure0: RTL8156 (0x7030), address 00:e0:4c:ab:64:5a
>>
>> Thanks for the report. Could you test this diff? Thanks.
>
> Thank you for the quick patch.
>
> I have run this at 40-50MB/s for ~20mins for both RTL8153 and RTL8156.
>
> No panic with your patch.
>
> I am going to leave it running with the RTL8156 and will send an update if I
> see any problems.
Kevin,
This happened with the patch applied and using the RTL8156.
Same dmesg as original report.
assertwaitok: non-zero mutex count: 1
Stopped at db_enter+0xl0: popq %rbp
TID PID UID PRFLRGS PFLAGS CPU COMMAND
db_enter() at db_enter+0xl0
panic(81c8e578) at panic+0xl28
assertwaitok() at assertwaitok+0xc7
mi_suitch() at mi_switch+0x40
sleep_finish(800022e81148,1) at sleep_finish+0x84
sleep_finish_all(800022e81148,l) at sleep_finish_al1+0x21
tsleep(fd84465a24b0,10,81c9bd4f,0) at tsleep+0xd6
usbd_transfer(fd84465a24b0) at usbd_transfer+0x204
usbd_do_request_flags(8052d500,800022e812a0,800022e8129c,0,0,1388)
at usbd_do_request_flags+0x139
ure_reset(80533000) at ure_reset+0x5e
ure_stop(80533000) at ure_stop+0x21
ure_encap(80533000,fd808ecf9800,5) at ure_encap+0xf6
ure_start(805330d0) at ure_start+0x98
if_qstart_compat(80533348) at if_qstart_compat+0x2e
end trace frame: 0x800022e81450, count: 0
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{1}>
Thanks,
Jonathon
OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink
Hi everyone,
After a few hours OpenBSD 6.7 crashes to ddb> . Without a LTE modem OpenBSD 6.7
works stable. Huawei E3372s-153 HiLink on OpenBSD 6.6 works perfectly, stable.
Something wrong with USB, xHCI or cdce on OpenBSD 6.7 imho.
ddb{2}> show panic
assertwaitok: non-zero mutex count: 1
ddb{2}> trace
db_enter() at db_enter+0x10
panic(81c8ec25) at panic+0x128
assertwaitok() at assertwaitok+0xc7
mi_switch() at mi_switch+0x40
sleep_finish(8000225b8f88,1) at sleep_finish+0x84
sleep_finish_all(8000225b8f88,1) at sleep_finish_all+0x21
tsleep(800a5750,16,81c99248,33) at tsleep+0xd6
xhci_command_submit(8009,8000225b9078,1dcd6500) at xhci_command
_submit+0x13f
xhci_abort_xfer(fd811e918690,6) at xhci_abort_xfer+0x13a
usbd_abort_pipe(8045f000) at usbd_abort_pipe+0x3d
cdce_stop(80119000) at cdce_stop+0x46
cdce_encap(80119000,fd80df8b8400,0) at cdce_encap+0xf7
cdce_start(80119048) at cdce_start+0x84
if_qstart_compat(801192c0) at if_qstart_compat+0x2e
ifq_serialize(801192c0,80119390) at ifq_serialize+0x103
taskq_thread(800290c0) at taskq_thread+0x4d
end trace frame: 0x0, count: -16
PC Engines apu2
coreboot build 20202604
BIOS version v4.11.0.6
4080 MB ECC DRAM
SeaBIOS (version rel-1.12.1.3-0-g300e8b70)
root@master[~]usbdevs -v
Controller /dev/usb0:
addr 01: 1022: AMD, xHCI root hub
super speed, self powered, config 1, rev 1.00
driver: uhub0
addr 02: 12d1:14dc HUAWEI_MOBILE, HUAWEI_MOBILE
high speed, self powered, config 1, rev 1.02
driver: cdce0
driver: umass0
Controller /dev/usb1:
addr 01: 1022: AMD, EHCI root hub
high speed, self powered, config 1, rev 1.00
driver: uhub1
addr 02: 0438:7900 Advanced Micro Devices, Hub
high speed, self powered, config 1, rev 0.18
driver: uhub2
root@master[~]usbdevs -vv
Controller /dev/usb0:
addr 01: 1022: AMD, xHCI root hub
super speed, self powered, config 1, rev 1.00
driver: uhub0
port 01: .02a0 power Rx.detect
port 02: .02a0 power Rx.detect
port 03: .0503 connect enabled recovery
port 04: .02a0 power Rx.detect
addr 02: 12d1:14dc HUAWEI_MOBILE, HUAWEI_MOBILE
high speed, self powered, config 1, rev 1.02
driver: cdce0
driver: umass0
Controller /dev/usb1:
addr 01: 1022: AMD, EHCI root hub
high speed, self powered, config 1, rev 1.00
driver: uhub1
port 01: .0503 connect enabled power
port 02: .0500 power
addr 02: 0438:7900 Advanced Micro Devices, Hub
high speed, self powered, config 1, rev 0.18
driver: uhub2
port 01: .0100 power
port 02: .0100 power
port 03: .0100 power
port 04: .0100 power
root@master[~]ifconfig cdce0
cdce0: flags=8843 mtu 1500
lladdr xx:xx:xx:xx:xx:xx
index 6 priority 0 llprio 3
inet 192.168.8.100 netmask 0xff00 broadcast 192.168.8.255
root@master[~]dmesg
OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020
r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4259880960 (4062MB)
avail mem = 4118163456 (3927MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xcfe8d020 (13 entries)
bios0: vendor coreboot version "v4.11.0.6" date 04/26/2020
bios0: PC Engines apu2
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST SSDT SSDT HPET
acpi0: wakeup devices PWRB(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4)
UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-64
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD GX-412TC SOC, 998.27 MHz, 16-30-01
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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD GX-412TC SOC, 998.17 MHz, 16-30-01
cpu1:
Re: cannot clean-install KVM/QEMU VM that don't support MSR_TSX_CTRL
> 1) Broken emulator > 2) Old broken emulator > > A real cpu behaves that way. The capability bits says the feature > exists, and when it exists, it MUST work. Yes, I think KVM/QEMU may be malfunction and I found a patch for QEMU that supports MSR_TSX_CTRL. https://www.mail-archive.com/qemu-devel@nongnu.org/msg660546.html > Have you have filed a bug with the authors of the emulator? So I didn't write any bug report to them. > If newer code emulators have it fixed, then again, how is this our > fault for using the feature as advertised in all real hardware? It may be no problem that running KVM/QEMU locally (simply install new emulator by myself), but I found this MSR_TSX_CTRL problem on VPS service. I understand that I have to consult support desk of the service provider and ask them to update QEMU. Regards, -- SASANO Takayoshi (JG1UAA)
Re: ksh: failing eval stops execution even when in OR-list
Comitted, Thanks!
Leah Neukirchen(l...@vuxu.org) on 2020.05.20 21:18:09 +0200:
> Leah Neukirchen writes:
>
> >>Synopsis: ksh: failing eval stops execution even when in OR-list
>
> I noticed this issue else appears only in pdksh, but not in mksh.
> Bisecting mksh I found this fixed between R21 and R22,
> in this commit:
> https://github.com/MirBSD/mksh/commit/ba859c9ab1d7bae5a70c0d094f5a39669e8f81ef
>
> This Debian bug report from 2004 shows that it also occured in
> other shells that fixed it since then:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=269067
>
> Here's a patch that fixes it, but it's more an idea of what someone
> experienced with the code base could look for:
>
> --- a/c_sh.c
> +++ b/c_sh.c
> @@ -424,6 +424,8 @@ int
> c_eval(char **wp)
> {
> struct source *s;
> + struct source *saves = source;
> + int savef;
> int rv;
>
> if (ksh_getopt(wp, _opt, null) == '?')
> @@ -458,7 +460,11 @@ c_eval(char **wp)
> exstat = subst_exstat;
> }
>
> + savef = Flag(FERREXIT);
> + Flag(FERREXIT) = 0;
> rv = shell(s, false);
> + Flag(FERREXIT) = savef;
> + source = saves;
> afree(s, ATEMP);
> return (rv);
> }
>
>
> Cheers,
> --
> Leah Neukirchenhttps://leahneukirchen.org/
>
