Re: Capturing redirected packets?
> On 10 Feb 2022, at 18:55, Stuart Henderson wrote: > > Normally if you have two addresses on the same lan you'd configure them > as aliases on the one interface, this seems a bit of a non-standard > config. If aggr/trunk to increase bandwidth makes sense, then you can think of configuring multiple IPs on different interfaces on the same network as the same kind of thing but at layer 3 instead of at layer 2. It's just ECMP. If you have the net.inet.ip.multipath sysctl set to 1 it should work, but I think we need an rtable diff I've had in my back pocket for a few years for dealing with the ARP side of things to actually make it work. dlg
Re: What happened to www/art on CVSWeb? Why is it empty?
It is empty because we have other more important things to take care of. Our sincere apologies for the inconvenience. Kacper Wilgus wrote: > I tried to download some artwork from these pages: > > https://www.openbsd.org/art1.html > https://www.openbsd.org/art2.html > https://www.openbsd.org/art3.html > > But only the first one has an image, the rest of them give me 404 > errors and I swear they used to be there just a year ago. And the > wayback machine proves this. Was it an error, or copyright issues? > It seems wierd it was just snapped out of existence without any warning. > > -- > Kacper Wilgus >
Re: dmesg - cpu, smt, core, package
I did set hw.smt=1 and all are shown now "online". I'm a little bit worry since I switched to this cpu from a 2 core AMD. Total mess in the CPU manufacturer yard. But we cannot produce our own cpu in the kitchen, can't we? # sysctl hw.smt=1 hw.smt: 0 -> 1 hw.machine=amd64 hw.model=AMD A8-5500B APU with Radeon(tm) HD Graphics hw.ncpu=4 hw.byteorder=1234 hw.pagesize=4096 hw.disknames=sd0:b10ceaa38ac5ec4d,cd0: hw.diskcount=2 hw.sensors.km0.temp0=0.00 degC hw.cpuspeed=3200 hw.setperf=100 hw.vendor=Hewlett-Packard hw.product=HP Compaq Pro 6305 SFF hw.serialno=CZC3515JBD hw.uuid=809987e8-6e63-e311-8653-fb3620fd442c hw.physmem=7711543296 hw.usermem=7711526912 hw.ncpufound=4 hw.allowpowerdown=1 hw.perfpolicy=auto hw.smt=1 hw.ncpuonline=4 hw.power=1
Re: dmesg - cpu, smt, core, package
On 2022-02-10, Mihai Popescu wrote: > I see in the AMD spec that I have a 4 core CPU, no *-threading. So it > is 4 core, 4 threads, no multi, simultaneous, hyper, etc. > Still the sysctl hw.ncpuonline reports 2, but it found 4 and top > displays CPU0 and CPU2 only ( that is 2). I am aware that each pair of > cores is using a shared FPU. > > My question is, how many CPU cores is using OpenBSD from that CPU? 2, because that's what is reported in hw.ncpuonline. And the reason it is 2, is because the hardware is replying to the CPUID instruction that two of the "cpu"s are actually smt rather than full cpus, and because hw.smt is at the default. It's possible that AMD made the decision to answer that way based on the shared FPU, I don't know.
Re: dmesg - cpu, smt, core, package
On 10.2.2022. 20:03, Mihai Popescu wrote: >> you mean gaps because HT is disabled ? > > I think they are disabled from the factory, cores that are not 100% > functional, i.e defects. > There is one line for a family, the luckiest ones have the maximum > number of cores and $$$, the rest are lower but still functional on > the advertised cores. > if i enable only 4 core per CCD (not sure if this is right term) i'm getting right numbers without HT smc24# dmesg | grep smt cpu0: smt 0, core 0, package 0 cpu1: smt 0, core 1, package 0 cpu2: smt 0, core 2, package 0 cpu3: smt 0, core 3, package 0 cpu4: smt 0, core 4, package 0 cpu5: smt 0, core 5, package 0 cpu6: smt 0, core 6, package 0 cpu7: smt 0, core 7, package 0 cpu8: smt 0, core 8, package 0 cpu9: smt 0, core 9, package 0 cpu10: smt 0, core 10, package 0 cpu11: smt 0, core 11, package 0 cpu12: smt 0, core 12, package 0 cpu13: smt 0, core 13, package 0 cpu14: smt 0, core 14, package 0 cpu15: smt 0, core 15, package 0 with HT smc24# dmesg | grep smt cpu0: smt 0, core 0, package 0 cpu1: smt 0, core 1, package 0 cpu2: smt 0, core 2, package 0 cpu3: smt 0, core 3, package 0 cpu4: smt 0, core 4, package 0 cpu5: smt 0, core 5, package 0 cpu6: smt 0, core 6, package 0 cpu7: smt 0, core 7, package 0 cpu8: smt 0, core 8, package 0 cpu9: smt 0, core 9, package 0 cpu10: smt 0, core 10, package 0 cpu11: smt 0, core 11, package 0 cpu12: smt 0, core 12, package 0 cpu13: smt 0, core 13, package 0 cpu14: smt 0, core 14, package 0 cpu15: smt 0, core 15, package 0 cpu16: smt 1, core 0, package 0 cpu17: smt 1, core 1, package 0 cpu18: smt 1, core 2, package 0 cpu19: smt 1, core 3, package 0 cpu20: smt 1, core 4, package 0 cpu21: smt 1, core 5, package 0 cpu22: smt 1, core 6, package 0 cpu23: smt 1, core 7, package 0 cpu24: smt 1, core 8, package 0 cpu25: smt 1, core 9, package 0 cpu26: smt 1, core 10, package 0 cpu27: smt 1, core 11, package 0 cpu28: smt 1, core 12, package 0 cpu29: smt 1, core 13, package 0 cpu30: smt 1, core 14, package 0 cpu31: smt 1, core 15, package 0 this if funny :)
Re: dmesg - cpu, smt, core, package
> you mean gaps because HT is disabled ? I think they are disabled from the factory, cores that are not 100% functional, i.e defects. There is one line for a family, the luckiest ones have the maximum number of cores and $$$, the rest are lower but still functional on the advertised cores.
Re: What happened to www/art on CVSWeb? Why is it empty?
Aren't they under images/ ? Den tors 10 feb. 2022 17:53Marc Espie skrev: > On Thu, Feb 10, 2022 at 11:25:40AM -0500, Nick Holland wrote: > > On 2/10/22 6:34 AM, Kacper Wilgus wrote: > > > I tried to download some artwork from these pages: > > > > > > https://www.openbsd.org/art1.html > > > https://www.openbsd.org/art2.html > > > https://www.openbsd.org/art3.html > > > > > > But only the first one has an image, the rest of them give me 404 > > > errors and I swear they used to be there just a year ago. And the > > > wayback machine proves this. Was it an error, or copyright issues? > > > It seems wierd it was just snapped out of existence without any > warning. > > > > > > > art[123].html hasn't been referenced from the main page since OpenBSD 5.8 > > (see the removal in version 1.686 of index.html, and they are not > currently > > referenced in any page on the website other than art[123].html so I think > > it is safe to say it was not being maintained and deleted at some point. > > > > I have no other info than it looks like the "problem" is more the > > continued existence of art[123].html more than the missing images. > > > > Nick. > > > > > A quick look at the full cvs repository shows a few .jpg and QUITE a few > .gif in the Attic. > > Just saying ;) > >
Re: dmesg - cpu, smt, core, package
On 10.2.2022. 16:38, Todd C. Miller wrote: > On Thu, 10 Feb 2022 08:46:37 +, Stuart Henderson wrote: > >> The numbers come from what's reported by the relevant CPUID instruction, >> the only one actually used by OpenBSD is smt to disable all but one >> thread in a core, otherwise they're just for information. >> >> I'm not sure the reason for the gaps in numbering on some AMDs, but the >> documentation just talks about IDs and doesn't imply that they have to >> be contiguous. (https://www.amd.com/system/files/TechDocs/24594.pdf >> page 629). > > I'd guess that the gaps represent cores present on the chiplet that > have been disabled. > > - todd > you mean gaps because HT is disabled ? this is with HT enabled smc24# dmesg | grep smt cpu0: smt 0, core 0, package 0 cpu1: smt 0, core 1, package 0 cpu2: smt 0, core 2, package 0 cpu3: smt 0, core 3, package 0 cpu4: smt 0, core 4, package 0 cpu5: smt 0, core 5, package 0 cpu6: smt 0, core 8, package 0 cpu7: smt 0, core 9, package 0 cpu8: smt 0, core 10, package 0 cpu9: smt 0, core 11, package 0 cpu10: smt 0, core 12, package 0 cpu11: smt 0, core 13, package 0 cpu12: smt 0, core 16, package 0 cpu13: smt 0, core 17, package 0 cpu14: smt 0, core 18, package 0 cpu15: smt 0, core 19, package 0 cpu16: smt 0, core 20, package 0 cpu17: smt 0, core 21, package 0 cpu18: smt 0, core 24, package 0 cpu19: smt 0, core 25, package 0 cpu20: smt 0, core 26, package 0 cpu21: smt 0, core 27, package 0 cpu22: smt 0, core 28, package 0 cpu23: smt 0, core 29, package 0 cpu24: smt 1, core 0, package 0 cpu25: smt 1, core 1, package 0 cpu26: smt 1, core 2, package 0 cpu27: smt 1, core 3, package 0 cpu28: smt 1, core 4, package 0 cpu29: smt 1, core 5, package 0 cpu30: smt 1, core 8, package 0 cpu31: smt 1, core 9, package 0 cpu32: smt 1, core 10, package 0 cpu33: smt 1, core 11, package 0 cpu34: smt 1, core 12, package 0 cpu35: smt 1, core 13, package 0 cpu36: smt 1, core 16, package 0 cpu37: smt 1, core 17, package 0 cpu38: smt 1, core 18, package 0 cpu39: smt 1, core 19, package 0 cpu40: smt 1, core 20, package 0 cpu41: smt 1, core 21, package 0 cpu42: smt 1, core 24, package 0 cpu43: smt 1, core 25, package 0 cpu44: smt 1, core 26, package 0 cpu45: smt 1, core 27, package 0 cpu46: smt 1, core 28, package 0 cpu47: smt 1, core 29, package 0 dmesg OpenBSD 7.0-current (GENERIC.MP) #323: Wed Feb 9 21:05:37 MST 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 68497002496 (65323MB) avail mem = 66403860480 (63327MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.3 @ 0xa9d1c000 (71 entries) bios0: vendor American Megatrends Inc. version "2.3" date 10/20/2021 bios0: Supermicro AS -1114S-WTRT acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP SSDT SPMI SSDT FIDT MCFG SSDT SSDT BERT HPET IVRS PCCT SSDT CRAT CDIT SSDT WSMT APIC ERST HEST acpi0: wakeup devices B000(S3) C000(S3) B010(S3) C010(S3) B030(S3) C030(S3) B020(S3) C020(S3) B100(S3) C100(S3) B110(S3) C110(S3) B130(S3) C130(S3) B120(S3) C120(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD EPYC 7413 24-Core Processor, 2650.38 MHz, 19-01-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,FMA3,CX16,PCID,SSE4.1,SSE4.2,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,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 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, C-substates=1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: AMD EPYC 7413 24-Core Processor, 2650.00 MHz, 19-01-01 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,PCID,SSE4.1,SSE4.2,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,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way
Re: dmesg - cpu, smt, core, package
I see in the AMD spec that I have a 4 core CPU, no *-threading. So it is 4 core, 4 threads, no multi, simultaneous, hyper, etc. Still the sysctl hw.ncpuonline reports 2, but it found 4 and top displays CPU0 and CPU2 only ( that is 2). I am aware that each pair of cores is using a shared FPU. My question is, how many CPU cores is using OpenBSD from that CPU? Thanks.
Re: Capturing redirected packets?
On 2022-02-10, Mike Fischer wrote: >> The redirection to an address on the local machine is just internal to >> the machine; those would only show a second time in tcpdump if they were >> being sent to another machine. > > Ok, thanks. So there is no way to trace rdr-to (other than possibly doing low > level kernel debugging)? See pflog(4) - "match log(matches)" is very useful for tracking through fiddly rulesets. >> Normally if you have two addresses on the same lan you'd configure them >> as aliases on the one interface, this seems a bit of a non-standard >> config. > > Yes I know. The reason for trying this was that having two > inet6 autoconf interfaces on the same LAN has issues. And alias > was not an option due to dynamic IPv6 prefixes. (See this > thread: https://marc.info/?l=openbsd-misc=164412170710420=2 > and a suggestion by Brian Brombacher in > https://marc.info/?l=openbsd-misc=164418424619191=2 that I wanted to > give a try.) > > Non-standard or not, it works ;-) Though the headers seen by the web > server show the redirected IP and port and not the ones originally asked > for by the client. Not surprising but something the site developer needs > to be aware of. And HTTP was only an easy to use example. For other > services this limitation may have more severe consequences. Ah yes I do remember reading this, but I couldn't figure out a use case for doing it that way :) I'm not a fan of non-standard configs where avoidable, they're usually the ones which get broken when things are changed. btw for "only the prefix is listed not the complete IPv6 addresses" -> see netstat's -v flag.
Re: Capturing redirected packets?
> Am 10.02.2022 um 09:55 schrieb Stuart Henderson : > > On 2022-02-08, Mike Fischer wrote: >> Hi! >> >> I have PF rules redirecting packets to an IP on one interface (rdomain 1) to >> the IP of another interface (rdomain 0): >> >> pass in log on rdomain 1 inet proto tcp to $ipv4b port 80 rdr-to $ipv4a port >> 8080 rtable 0 >> pass in log on rdomain 1 inet6 proto tcp to $ipv6b port 80 rdr-to $ipv6a >> port 8080 rtable 0 >> >> These rules work for IPv4 but initially not for IPv6. (That problem is now >> solved.) I was trying to figure out why and started using tcpdump(8). >> >> em0 has the IPs: ipv4a and ipv6a. >> em1 is in rdomain 1 and has the IPs: ipv4b and ipv6b. >> Both are connected to the same LAN. >> >> httpd(8) is configured to listen on ipv4a:80, ipv6a:80 with one (virtual) >> server and on ipv4a:8080, ipv6a:8080 with another, each serving a very >> simple index.html file that shows which server is responding. >> >> To debug I started: >> # tcpdump -n -e -ttt -l -i em0 'port 80 or 8080‘ >> >> # tcpdump -n -e -ttt -l -i em1 'port 80 or 8080‘ >> >> (Both in separate terminal windows at the same time.) >> >> Now from a second machine I access the web server: >> $ curl --url 'http://‘ >> Works fine, I see traffic in the tcpdump(8) for em0. >> >> $ curl --url 'http://‘ >> Works fine, I see traffic in the tcpdump(8) for em1 but not for em0. >> >> $ curl --url 'http://[]‘ >> Works fine, I see traffic in the tcpdump(8) for em0. >> >> $ curl --url 'http://[]‘ >> Timeout! I see traffic in the tcpdump(8) for em1 but not for em0. >> This was the one I was ultimately trying to debug but as the trace on the >> IPv4 version doesn’t work as expected I was momentarily at a loss. >> I have since solved the actual problem by setting: >> # sysctl net.inet6.ip6.forwarding=1 >> But I still don’t see the redirected traffic in the tcpdump(8) for em0. >> >> >> I don’t understand the second and fourth results. Why does the tcpdump(8) >> for em0 not show the redirected packets? >> >> I am likely missing something obvious here. How can I capture the redirected >> packets? > > The redirection to an address on the local machine is just internal to > the machine; those would only show a second time in tcpdump if they were > being sent to another machine. Ok, thanks. So there is no way to trace rdr-to (other than possibly doing low level kernel debugging)? > Normally if you have two addresses on the same lan you'd configure them > as aliases on the one interface, this seems a bit of a non-standard > config. Yes I know. The reason for trying this was that having two inet6 autoconf interfaces on the same LAN has issues. And alias was not an option due to dynamic IPv6 prefixes. (See this thread: https://marc.info/?l=openbsd-misc=164412170710420=2 and a suggestion by Brian Brombacher in https://marc.info/?l=openbsd-misc=164418424619191=2 that I wanted to give a try.) Non-standard or not, it works ;-) Though the headers seen by the web server show the redirected IP and port and not the ones originally asked for by the client. Not surprising but something the site developer needs to be aware of. And HTTP was only an easy to use example. For other services this limitation may have more severe consequences. Thanks! Mike
Re: dmesg - cpu, smt, core, package
On 2022-02-10, Mihai Popescu wrote: >> ... gaps ... > > What gaps are you referring to? The ones in dmesg for Intel in OP? in Hrvoje's dmesg for AMD. > Also the smt is from simultaneous multithreading? yes (hyperthreading on Intel CPUs), these are what are disabled by the default setting hw.smt=0 on amd64 (i.e. only one of the detected "cpu"s is used per core) https://marc.info/?l=openbsd-cvs=152943660103446=2
Re: What happened to www/art on CVSWeb? Why is it empty?
On Thu, Feb 10, 2022 at 11:25:40AM -0500, Nick Holland wrote: > On 2/10/22 6:34 AM, Kacper Wilgus wrote: > > I tried to download some artwork from these pages: > > > > https://www.openbsd.org/art1.html > > https://www.openbsd.org/art2.html > > https://www.openbsd.org/art3.html > > > > But only the first one has an image, the rest of them give me 404 > > errors and I swear they used to be there just a year ago. And the > > wayback machine proves this. Was it an error, or copyright issues? > > It seems wierd it was just snapped out of existence without any warning. > > > > art[123].html hasn't been referenced from the main page since OpenBSD 5.8 > (see the removal in version 1.686 of index.html, and they are not currently > referenced in any page on the website other than art[123].html so I think > it is safe to say it was not being maintained and deleted at some point. > > I have no other info than it looks like the "problem" is more the > continued existence of art[123].html more than the missing images. > > Nick. > > A quick look at the full cvs repository shows a few .jpg and QUITE a few .gif in the Attic. Just saying ;)
Re: dmesg - cpu, smt, core, package
> ... gaps ... What gaps are you referring to? The ones in dmesg for Intel in OP? Also the smt is from simultaneous multithreading? top also has a strange report, but i think is is known. sysctl hw. has 2 cpu online from 4 found. load averages: 0.37, 0.43, 0.21hp.my.domain 18:26:19 51 processes: 50 idle, 1 on processor up 3:40 CPU0: 2.5% user, 0.0% nice, 0.5% sys, 0.1% spin, 0.2% intr, 96.8% idle CPU2: 3.8% user, 0.0% nice, 1.1% sys, 0.1% spin, 0.0% intr, 95.0% idle Thanks. hw.machine=amd64 hw.model=AMD A8-5500B APU with Radeon(tm) HD Graphics hw.ncpu=4 hw.byteorder=1234 hw.pagesize=4096 hw.disknames=sd0:b10ceaa38ac5ec4d,cd0: hw.diskcount=2 hw.sensors.km0.temp0=0.00 degC hw.cpuspeed=3200 hw.setperf=100 hw.vendor=Hewlett-Packard hw.product=HP Compaq Pro 6305 SFF hw.serialno=CZC3515JBD hw.uuid=809987e8-6e63-e311-8653-fb3620fd442c hw.physmem=7711543296 hw.usermem=7711526912 hw.ncpufound=4 hw.allowpowerdown=1 hw.perfpolicy=auto hw.smt=0 hw.ncpuonline=2 hw.power=1 OpenBSD 7.0-current (GENERIC.MP) #321: Tue Feb 8 21:10:57 MST 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 7711543296 (7354MB) avail mem = 7460614144 (7114MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe86ed (64 entries) bios0: vendor Hewlett-Packard version "K06 v02.77" date 03/22/2018 bios0: Hewlett-Packard HP Compaq Pro 6305 SFF acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT MSDM TCPA IVRS SSDT SSDT CRAT acpi0: wakeup devices SBAZ(S4) PS2K(S3) PS2M(S3) P0PC(S4) PE20(S4) PE21(S4) PE22(S4) BNIC(S4) PE23(S4) BR12(S4) BR14(S4) OHC1(S3) EHC1(S3) OHC2(S3) EHC2(S3) OHC3(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 16 (boot processor) cpu0: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.46 MHz, 15-10-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,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 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 17 (application processor) cpu1: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.03 MHz, 15-10-01 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,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: disabling user TSC (skew=135) cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 18 (application processor) cpu2: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.05 MHz, 15-10-01 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,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB cpu2: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: disabling user TSC (skew=219) cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 19 (application processor) cpu3: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.04 MHz, 15-10-01 cpu3: 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,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB cpu3: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu3:
Re: What happened to www/art on CVSWeb? Why is it empty?
On 2/10/22 6:34 AM, Kacper Wilgus wrote: I tried to download some artwork from these pages: https://www.openbsd.org/art1.html https://www.openbsd.org/art2.html https://www.openbsd.org/art3.html But only the first one has an image, the rest of them give me 404 errors and I swear they used to be there just a year ago. And the wayback machine proves this. Was it an error, or copyright issues? It seems wierd it was just snapped out of existence without any warning. art[123].html hasn't been referenced from the main page since OpenBSD 5.8 (see the removal in version 1.686 of index.html, and they are not currently referenced in any page on the website other than art[123].html so I think it is safe to say it was not being maintained and deleted at some point. I have no other info than it looks like the "problem" is more the continued existence of art[123].html more than the missing images. Nick.
Re: dmesg - cpu, smt, core, package
On Thu, 10 Feb 2022 08:46:37 +, Stuart Henderson wrote: > The numbers come from what's reported by the relevant CPUID instruction, > the only one actually used by OpenBSD is smt to disable all but one > thread in a core, otherwise they're just for information. > > I'm not sure the reason for the gaps in numbering on some AMDs, but the > documentation just talks about IDs and doesn't imply that they have to > be contiguous. (https://www.amd.com/system/files/TechDocs/24594.pdf > page 629). I'd guess that the gaps represent cores present on the chiplet that have been disabled. - todd
Re: Capturing redirected packets?
On 2022-02-08, Mike Fischer wrote: > Hi! > > I have PF rules redirecting packets to an IP on one interface (rdomain 1) to > the IP of another interface (rdomain 0): > > pass in log on rdomain 1 inet proto tcp to $ipv4b port 80 rdr-to $ipv4a port > 8080 rtable 0 > pass in log on rdomain 1 inet6 proto tcp to $ipv6b port 80 rdr-to $ipv6a port > 8080 rtable 0 > > These rules work for IPv4 but initially not for IPv6. (That problem is now > solved.) I was trying to figure out why and started using tcpdump(8). > > em0 has the IPs: ipv4a and ipv6a. > em1 is in rdomain 1 and has the IPs: ipv4b and ipv6b. > Both are connected to the same LAN. > > httpd(8) is configured to listen on ipv4a:80, ipv6a:80 with one (virtual) > server and on ipv4a:8080, ipv6a:8080 with another, each serving a very simple > index.html file that shows which server is responding. > > To debug I started: > # tcpdump -n -e -ttt -l -i em0 'port 80 or 8080‘ > > # tcpdump -n -e -ttt -l -i em1 'port 80 or 8080‘ > > (Both in separate terminal windows at the same time.) > > Now from a second machine I access the web server: > $ curl --url 'http://‘ > Works fine, I see traffic in the tcpdump(8) for em0. > > $ curl --url 'http://‘ > Works fine, I see traffic in the tcpdump(8) for em1 but not for em0. > > $ curl --url 'http://[]‘ > Works fine, I see traffic in the tcpdump(8) for em0. > > $ curl --url 'http://[]‘ > Timeout! I see traffic in the tcpdump(8) for em1 but not for em0. > This was the one I was ultimately trying to debug but as the trace on the > IPv4 version doesn’t work as expected I was momentarily at a loss. > I have since solved the actual problem by setting: > # sysctl net.inet6.ip6.forwarding=1 > But I still don’t see the redirected traffic in the tcpdump(8) for em0. > > > I don’t understand the second and fourth results. Why does the tcpdump(8) for > em0 not show the redirected packets? > > I am likely missing something obvious here. How can I capture the redirected > packets? The redirection to an address on the local machine is just internal to the machine; those would only show a second time in tcpdump if they were being sent to another machine. Normally if you have two addresses on the same lan you'd configure them as aliases on the one interface, this seems a bit of a non-standard config. -- Please keep replies on the mailing list.
Re: dmesg - cpu, smt, core, package
On 2022-02-09, Hrvoje Popovski wrote: > On 9.2.2022. 19:04, Kapetanakis Giannis wrote: >> On 09/02/2022 19:48, Mihai Popescu wrote: >>> $ dmesg | grep smt >>> cpu0: smt 0, core 0, package 0 >>> cpu1: smt 1, core 0, package 0 >>> cpu2: smt 0, core 1, package 0 >>> cpu3: smt 1, core 1, package 0 >>> >>> for >>> >>> AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.46 MHz, 15-10-01 >>> >>> What could be the "smt" thing? >>> >> >> multi threading >> >> # sysctl hw.smt >> >> G >> > > and i think that "package" is cpu socket .. Yes. The numbers come from what's reported by the relevant CPUID instruction, the only one actually used by OpenBSD is smt to disable all but one thread in a core, otherwise they're just for information. I'm not sure the reason for the gaps in numbering on some AMDs, but the documentation just talks about IDs and doesn't imply that they have to be contiguous. (https://www.amd.com/system/files/TechDocs/24594.pdf page 629).
