Re: hw.ncpu=1, hw.ncpuonline=1, hw.ncpufound=4
On Mon, May 27, 2019 at 6:18 PM Ipsen S Ripsbusker < ips...@ripsbusker.no.eu.org> wrote: > Aaron Mason writes: > > Looks to me like you're not running bsd.mp. A dmesg would clear this > up. > > Indeed I was not running bsd.mp. I switched to bsd.mp, and then 2 of 4 > CPUs were online. Then I set "sysctl hw.smt = 1" to get all 4 online. > This is a side-point, but you do understand that those extra 2 aren't full CPUs, they're just the cardboard mockups that Intel sold you, and that if you run any untrusted code (including javascript in a web-browser) that those fake CPUs leak data across process boundaries, right? > Otto Moerbeek writes: > > On Sun, Apr 07, 2019 at 01:54:35PM +, Ipsen S Ripsbusker wrote: > > > ... > > > Also, now that I have realized this, I have a theory about a related > > > issue, and I would like to know how I can debug it. I am using softraid > > > CRYPTO, and I have found that accessing the disk with one process will > > > interrupt the other processes accessing the disk. Now I wonder this > > > happens because the sole core must switch encryption/decription > > > processes for the different files. How could I determine whether this > is > > > indeed happening? > Can you explain in more detail what you were observing when you said "found that accessing the disk with one process will interrupt the other processes accessing the disk"? The word 'interrupt' is overloaded in computing and what you saw may be a real problem with device support, or it may be completely innocuous, something which you should be ignoring. Philip Guenther
Re: hw.ncpu=1, hw.ncpuonline=1, hw.ncpufound=4
Aaron Mason writes: > Looks to me like you're not running bsd.mp. A dmesg would clear this up. Indeed I was not running bsd.mp. I switched to bsd.mp, and then 2 of 4 CPUs were online. Then I set "sysctl hw.smt = 1" to get all 4 online. Otto Moerbeek writes: > On Sun, Apr 07, 2019 at 01:54:35PM +, Ipsen S Ripsbusker wrote: > > ... > > Also, now that I have realized this, I have a theory about a related > > issue, and I would like to know how I can debug it. I am using softraid > > CRYPTO, and I have found that accessing the disk with one process will > > interrupt the other processes accessing the disk. Now I wonder this > > happens because the sole core must switch encryption/decription > > processes for the different files. How could I determine whether this is > > indeed happening? > > ... > > This type of question *requires* a dmesg. > > -Otto The interruptions continued after I started using 2 CPUs, and they seem to have stopped now that I have 4 CPUs. I am still curious for real debugging though. Thanks $ dmesg OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16845565952 (16065MB) avail mem = 16325763072 (15569MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbae9c000 (69 entries) bios0: vendor LENOVO version "G4ETA7WW (2.67 )" date 08/24/2016 bios0: LENOVO 2392ASU acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! UEFI UEFI MSDM SSDT SSDT UEFI DBG2 acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) EHC2(S3) HDEF(S4) 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) cpu0: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.95 MHz, 06-3a-09 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,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 running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.43 MHz, 06-3a-09 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.43 MHz, 06-3a-09 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.43 MHz, 06-3a-09 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus 4 (EXP3) acpicpu0 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1, EHC2 acpitz0 at acpi0: critical temperature is 103 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpicmos0 at acpi0 tpm0 at acpi0: TPM_ addr 0xfed4/0x5000:
Re: PF firewall for desktop
IP is a fairly high-order construct. Beneath it , the data link and physical layers remain almost unnoticed. One thought that came to mind would be to attack a machine on the same LAN, and then exploit an Ethernet vulnerability to listen to "the wire". Not sure how many (if any) Ethernet vulnerabilities there are, but that would be one possible vector. Also, the nic card itself might have physical-layer vulnerabilities, such as administrative backdoors. That's all aimed at eavesdropping. Escalating that to an OS pwnership is beyond my imagination. But I imagine it's not beyond *somebody's* imagination. And that's the beauty of the hack. There's always someone in the rabble with a background in electronics or orchid-growing or intergalactic imaging that has an insight that nobody thought to defend. Check... No, wait, Checkmate! On Sun, May 26, 2019 at 4:04 AM Walt wrote: > ‐‐‐ Original Message ‐‐‐ > On Friday, May 24, 2019 2:30 PM, Jean-Francois Simon < > jfsimon1...@gmail.com> wrote: > > > Hi, > > > > Out of interest, I'd like to let you know a specific use of OpenBSD with > > PF, in virtualbox, 2 virtual network card Bridged to physical NIC, and > > building up a subnet with NAT and hence running Packet Filter as the > > machine's firewall. > > > > That's the firewall I use under Win7, OpenBSD running in a VM, out of > > pure interest into running BSD and let it purify the network access to > > desktop (without need for additional hardware). > > > > Works well, love it. > > > > Jean-François > > I like having a firewall that would pretty much require someone physically > entering the computer room in order to attack the firewall. With OpenBSD, > your firewall can control your network traffic without having an IP address > at all. > > One thing that you could try is to use the OpenBSD VM as the firewall, but > don't assign any IP address to the firewall. The Win7 VM would have the > actual IP address, but the OpenBSD VM would control the network. > > If I ever get around to getting enough IPv4 addresses so that I don't need > a NAT, I'll go back to isolating access to the firewall with this approach. > > I am curious if there is any way to attack the firewall if it has no IP > addresses. > > W > >
PCIe SFP Network Adapter's
Hoping to clarify if any PCI Express SFP adapters are currently considered compatible. I've recently upgraded my managed switch & now have two SFP 100/1000 uplinks. At this point I consider my existing Broadcom NetXtreme 10/100/1000 ethernet card stable However testing of SFP functionality on OpenBSD & PF seems worthwhile. A quick search turned up a StarTech PEX1000SFP2 with the following chipsets: Realtek - RTL8168E Marvell - 88EB1 Please note that I’m hoping to maintain desktop compatibility while implementing SFP. Regards Patrick
Re: Random system freeze.
On Mon, May 27, 2019 at 03:16:26PM +0200, Paco Esteban wrote: [...] > Later Karel Gardas suggested my RAM could be failing. I did a full test > with memtest86 which returned no errors. If somebody knows a better method > to test that (or if this tool is good enough to rule bad ram out), > please tell me. [...] I would too sucpect: it's a faulty RAM module. Give "stress" a try: https://people.seas.harvard.edu/~apw/stress/ Is this an IBM server? Test it with the DSA tools (Dynamis System Analysis). Marco.
Re: Random system freeze.
Hi Gregory, On Fri, 24 May 2019, Gregory Edigarov wrote: > Hi Paco, > > could you please check if you can login over network when the system > freeze? > if so - please do a backtrace of the X server. > i.e.: > > su - > gdb /usr/X11R6/bin/X `pgrep X` > bt Unfortunately I cannot login over ssh The system is non responsive when this happens (no icmp response, nothing ...). I was told to use sendbug to report this (and I did). Although I'm afraid the info I can provide may be useless. Later Karel Gardas suggested my RAM could be failing. I did a full test with memtest86 which returned no errors. If somebody knows a better method to test that (or if this tool is good enough to rule bad ram out), please tell me. Cheers, -- Paco Esteban. https://onna.be/gpgkey.asc 9A6B 6083 AD9E FDC2 0EAF 5CB3 5818 130B 8A6D BC03
Re: OpenBSD on thinkpad x280
Otto Moerbeek wrote: > On Mon, May 27, 2019 at 04:57:48AM -0600, Theo de Raadt wrote: > > > Claudio Jeker wrote: > > > > > On Sat, May 25, 2019 at 03:53:03PM +0100, Maurice McCarthy wrote: > > > > On 25/05/2019, Timo Myyrä wrote: > > > > > Tristan Pilat writes: > > > > > > > > > >> Hi OpenBSD users and devs! > > > > >> > > > > >> I got a new laptop in January, a thinkpad x280. At that time my > > > > >> system > > > > >> running 'current' was very slow and I assumed the video acceleration > > > > >> wasn't working so I just sadly stuck with Debian for a while. I then > > > > >> saw that an update of the inteldrm landed in current a month ago or > > > > >> so > > > > >> so I tried yesterday to reinstall current. Unfortunately the system > > > > >> is > > > > >> still barely usable. Could you guys tell me why the video > > > > >> acceleration > > > > >> isn't handled? Isn't Kaby lake compatible for now? I saw this article > > > > >> (https://jcs.org/2017/05/22/xiaomiair) which says it is. > > > > >> > > > > > > > > You may have to adjust the aperture > > > > See /etc/examples/sysctl.conf > > > > > > > > #machdep.allowaperture=2# See xf86(4) > > > > > > > > > > Nope. That does not help. I bet the issue is not related to anything > > > related to inteldrm. It is most probably an interrupt storm happening > > > because of Thunderbolt 3. At least that seems to be something people > > > complained about. > > > > Same sort of thing happened with x1rev6, but various folk figured out BIOS > > options which could prevent it, and newer BIOS replacements also improved > > the situation. Please study it and see if you can find some clues. > > I'm up-to-date with the newest BIOS on my X1 6th but I see acpi0 > eating lots of CPU if I connect a displayport device. Playing with > options does not fix this for me. The workaround I'm using now see > below) is very unsatisfactory, but I have no clue on where I should be > looking for a real fix and no one with knowledge in this area has > surfaced to look into this problem. > > -Otto > > Index: acpi.c > === > RCS file: /cvs/src/sys/dev/acpi/acpi.c,v > retrieving revision 1.367 > diff -u -p -r1.367 acpi.c > --- acpi.c12 May 2019 15:52:52 - 1.367 > +++ acpi.c27 May 2019 11:07:52 - > @@ -2262,6 +2262,10 @@ acpi_gpe(struct acpi_softc *sc, int gpe, > struct aml_node *node = arg; > uint8_t mask, en; > > + static unsigned short count111; > + if (gpe == 111 && count111++ != 0) > + return 0; > + > dnprintf(10, "handling GPE %.2x\n", gpe); > aml_evalnode(sc, node, 0, NULL, NULL); It is good clue to know what GPE is firing. Next step is to see what parts of AML use that GPE. (I still suspect it is related to Thunderbolt 3 / xhci / etc)
Re: OpenBSD on thinkpad x280
On Mon, May 27, 2019 at 04:57:48AM -0600, Theo de Raadt wrote: > Claudio Jeker wrote: > > > On Sat, May 25, 2019 at 03:53:03PM +0100, Maurice McCarthy wrote: > > > On 25/05/2019, Timo Myyrä wrote: > > > > Tristan Pilat writes: > > > > > > > >> Hi OpenBSD users and devs! > > > >> > > > >> I got a new laptop in January, a thinkpad x280. At that time my system > > > >> running 'current' was very slow and I assumed the video acceleration > > > >> wasn't working so I just sadly stuck with Debian for a while. I then > > > >> saw that an update of the inteldrm landed in current a month ago or so > > > >> so I tried yesterday to reinstall current. Unfortunately the system is > > > >> still barely usable. Could you guys tell me why the video acceleration > > > >> isn't handled? Isn't Kaby lake compatible for now? I saw this article > > > >> (https://jcs.org/2017/05/22/xiaomiair) which says it is. > > > >> > > > > > > You may have to adjust the aperture > > > See /etc/examples/sysctl.conf > > > > > > #machdep.allowaperture=2 # See xf86(4) > > > > > > > Nope. That does not help. I bet the issue is not related to anything > > related to inteldrm. It is most probably an interrupt storm happening > > because of Thunderbolt 3. At least that seems to be something people > > complained about. > > Same sort of thing happened with x1rev6, but various folk figured out BIOS > options which could prevent it, and newer BIOS replacements also improved > the situation. Please study it and see if you can find some clues. I'm up-to-date with the newest BIOS on my X1 6th but I see acpi0 eating lots of CPU if I connect a displayport device. Playing with options does not fix this for me. The workaround I'm using now see below) is very unsatisfactory, but I have no clue on where I should be looking for a real fix and no one with knowledge in this area has surfaced to look into this problem. -Otto Index: acpi.c === RCS file: /cvs/src/sys/dev/acpi/acpi.c,v retrieving revision 1.367 diff -u -p -r1.367 acpi.c --- acpi.c 12 May 2019 15:52:52 - 1.367 +++ acpi.c 27 May 2019 11:07:52 - @@ -2262,6 +2262,10 @@ acpi_gpe(struct acpi_softc *sc, int gpe, struct aml_node *node = arg; uint8_t mask, en; + static unsigned short count111; + if (gpe == 111 && count111++ != 0) + return 0; + dnprintf(10, "handling GPE %.2x\n", gpe); aml_evalnode(sc, node, 0, NULL, NULL);
Re: OpenBSD on thinkpad x280
Claudio Jeker wrote: > On Sat, May 25, 2019 at 03:53:03PM +0100, Maurice McCarthy wrote: > > On 25/05/2019, Timo Myyrä wrote: > > > Tristan Pilat writes: > > > > > >> Hi OpenBSD users and devs! > > >> > > >> I got a new laptop in January, a thinkpad x280. At that time my system > > >> running 'current' was very slow and I assumed the video acceleration > > >> wasn't working so I just sadly stuck with Debian for a while. I then > > >> saw that an update of the inteldrm landed in current a month ago or so > > >> so I tried yesterday to reinstall current. Unfortunately the system is > > >> still barely usable. Could you guys tell me why the video acceleration > > >> isn't handled? Isn't Kaby lake compatible for now? I saw this article > > >> (https://jcs.org/2017/05/22/xiaomiair) which says it is. > > >> > > > > You may have to adjust the aperture > > See /etc/examples/sysctl.conf > > > > #machdep.allowaperture=2# See xf86(4) > > > > Nope. That does not help. I bet the issue is not related to anything > related to inteldrm. It is most probably an interrupt storm happening > because of Thunderbolt 3. At least that seems to be something people > complained about. Same sort of thing happened with x1rev6, but various folk figured out BIOS options which could prevent it, and newer BIOS replacements also improved the situation. Please study it and see if you can find some clues.
