Re: Problems with a quad Realtek NIC
> It is preferable to just include the whole dmesg directly in the mail > Better still, when it's a "sometimes works" problem, include a "diff -u" > between the two (the context to show where the lines are added/removed). I have pasted a "diff -u" on https://paste.debian.net/1047098/ > Very unlikely to be a problem with the NIC driver. From what I've > seen (and having seen other examples of the quality of Jetway's BIOSes) > my money would be on a BIOS bug. I originally suspected it to be a BIOS bug (and please excuse me if I make a wrong assumption here), but I have run a ton of tests booting the same hardware up on Arch Linux, but I haven't seen the problem once. I don't know if could still be a BIOS bug, but I would suspect that if it where that I would see similar problems with the card not showing up. > Can you identify any particular situations where it works or fails? For > example "works after a cold boot but not warm" or something? I have been looking for patterns in the different tests I have run, but haven't found anything. Sometimes it works during a cold boot, other times it doesn't, and the same goes for warm boots. I have also tried disabling and enabling the onboard NIC to see if it might affect the problem, but it doesn't. Just for information, I have another identical box (same motherboard), but with a 4-port Intel NIC (same cheap card-thing from China, but with Intel) that runs flawless, but not only that, it performs super well even with several NIC ports going full speed. It has been running for a couple of years as a firewall/gateway, managing multiple networks (each separated by the 4-port NIC). I have made these as cheap alternatives to the very expensive Soekris. By mistake I got two of the 4-port Realtek cards, but since I got them, I wanted to see if they could run as well. Kindest regards. PS.: Sorry for the crappy Yandex mail client problem.
VMM sh: time sleep 30 takes 56 seconds
Hello, Not sure if this is a bug or not, so I thought I would ask misc@ first. I was writing a script in my vmm guest that involved killing and restarting a long running process every hour using sleep "3600", and I noticed it ended up sleeping for 2 hours and 56 minutes, rather than an hour. To test, I ran "time sleep 30" and got this result: vmm$ time sleep 30 0m57.50s real 0m00.00s user 0m00.00s system When run on bare metal, I get this result: server$ time sleep 30 0m30.00s real 0m00.00s user 0m00.00s system I have "sysctl kern.timecounter.hardware=tsc" set in the vm to prevent clock drift, otherwise the vm clock runs at around half speed. When "time sleep 30" is run on a vm without "sysctl kern.timecounter.hardware=tsc" set, it reports the correct amount of time being spent sleeping, but since the clock runs at around half speed without tsc enabled, it still ends up sleeping for almost a minute. The host machine is running 6.3 stable, the guest is running the latest snapshot. I tried running a 6.3-stable guest with the same results. Has this been fixed in current? I don't have a vmm capable machine available running current, I only own spare macppc and i386 hardware which runs current. Cheers, Jordan dmesg of the host machine: OpenBSD 6.3 (GENERIC.MP) #10: Wed Aug 22 16:42:31 CEST 2018 r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 68664565760 (65483MB) avail mem = 66576482304 (63492MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec0d0 (43 entries) bios0: vendor American Megatrends Inc. version "P1.80" date 12/09/2013 bios0: ASRock EP2C602 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG AAFT SRAT SLIT HPET PRAD SPMI SSDT SPCR EINJ ERST HEST BERT acpi0: wakeup devices UR11(S4) UR12(S4) P0P9(S1) EUSB(S4) USBE(S4) PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4) PEX6(S4) PEX7(S4) GBE_(S4) NPE1(S4) NPE2(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 2000.27 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache acpitimer0: recalibrated TSC frequency 200159 Hz 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 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 2000.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 2000.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 2000.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 8 (application processor) cpu4: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, 2000.00 MHz cpu4: 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,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 0, core 4, package 0 cpu5 at mainbus0: apid 10 (application
Re: Hyperthreading not disabled on E5-2690 v1?
Yep, I looked at the Top source after that and saw that the inactive CPU hiding code was backed out seven days ago. Running a make -j32 on a port shows that only CPUs 0-15 are active. Cheers! PK On Fri, 12 Oct 2018 at 21:41, Stuart Henderson wrote: > > On 2018-10-12, Peter Kay wrote: > > I can't see any recent source code changes about hyperthreading, and > > presume it's still supposed to be disabled by default? > > > > It is not disabled on an EP2C602 with two E5-2690 CPUs (Sandy Bridge > > EP), I can see 32 'CPUs' in both top and systat. > > > > Bug I presume..? Can provide dmesg, debugging info, and remote access > > if necessary. > > > > hw.smt is set to zero > > > > PK > > > > > > Currently I would expect them to show up but not have processes > scheduled to them. > >
Re: Graphical debugger for C/C++ ?
On Thu Oct 11, 2018 at 10:44:41AM +0100, Peter Kay wrote: > Just looking at writing a small enhancement to dhcpd, and starting to use > gdb properly for the first time. OK, it is functional, but it's a bit > awkward compared to graphical alternatives. > What does everyone use? I can see ddd and eclipse exist at least. > Typically I've used windbg on Windows (and historically various others > such as Watcom). > I don't have an issue typing in commands, but a constant display of > source and local/global variables would be terribly useful. Ideally plus > an arbitrary memory display, and some understanding of C/C++ structures. > PK I use devel/qt-creator[1] as a GUI GDB-interface and it works quit well. [1]: https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/devel/qt-creator/
Re: Hyperthreading not disabled on E5-2690 v1?
On 2018-10-12, Peter Kay wrote: > I can't see any recent source code changes about hyperthreading, and > presume it's still supposed to be disabled by default? > > It is not disabled on an EP2C602 with two E5-2690 CPUs (Sandy Bridge > EP), I can see 32 'CPUs' in both top and systat. > > Bug I presume..? Can provide dmesg, debugging info, and remote access > if necessary. > > hw.smt is set to zero > > PK > > Currently I would expect them to show up but not have processes scheduled to them.
Hyperthreading not disabled on E5-2690 v1?
I can't see any recent source code changes about hyperthreading, and presume it's still supposed to be disabled by default? It is not disabled on an EP2C602 with two E5-2690 CPUs (Sandy Bridge EP), I can see 32 'CPUs' in both top and systat. Bug I presume..? Can provide dmesg, debugging info, and remote access if necessary. hw.smt is set to zero PK
Re: carppeer question
On Fri, 12 Oct 2018 11:56:28 +0200 Marko Cupać wrote: > After introducing carppeer option I see incoming traffic on physical > interfaces of both MASTER and BACKUP firewalls, as opposed to the > situation without carppeer option, where I see incoming traffic on > physical interface of MASTER only. I hope I'm making some progress. I have set static non-multicast lladdr to my CARP interfaces (I have 3 of them - to ISP1, to ISP2 and to DMZ) for starters. I am also monitoring mac address table on a switch which connects my firewalls to above networks. Failing over with carpdemote results in clean failover, and switch mac address table shows both physical and CARP lladdrs on ports that connect to current MASTER, and only physical lladdrs on ports that connect to current BACKUP. However, rebooting BACKUP results (in my opinion) in strange situation, where switch's mac address table shows only MASTER's physical lladdrs, while CARP lladdrs go missing. When BACKUP comes back, lladdr of one of three CARP interfaces of MASTER appear immediately in switch's mac address table (DMZ), while the other two don't - respective switch ports show only physical lladdrs. Then, after a few minutes, another CARP lladdr shows up in switch's mac address table (ISP1), but the third one (ISP2) continues to show physical lladdr only, which results in incoming traffic on physical interfaces that connect to ISP2 of both CARP members. The situation seems to be self healing when designated BACKUP (higher advskew) takes the role of MASTER by increasing carpdemote on designated MASTER (lower advskew), and designated MASTER (currently BACKUP) reboots, at the moment when designated MASTER takes over MASTER role. But when designated BACKUP gets restarted, switching roles does not happen, MASTER stays MASTER, and switch's mac address table never updates port with CARP lladdr for ISP2. I am aware this is quite complex issue, presumably not related to OpenBSD itself but maybe to the switch (ATGS900MX). Still, I'd be very thankful for any advice on the matter. Regards, -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
Re: Problems with a quad Realtek NIC
On 2018-10-12, Aaron Mason wrote: > Wow, never seen a multi-port Realtek NIC before. I have but they're usually single NIC plus switch chip, looks like this is the real thing. > Maybe try the card on another motherboard and see if you get the same > symptoms. agreed if possible. > In any case, it's my understanding (and the maintainers of re(4) are > free to correct me on this) that Realtek NICs are usually a bad idea > for non-desktop applications, since they offload pretty much (if not > entirely) all of its functions to the OS - every time something > sneezes on the connected network, it raises an interrupt to the CPU. > This can lead to pretty craptacular performance and high CPU use under > heavy load. I can only imagine the hailstorm that would ensue if all > four of your NIC ports were running at full tilt. They're not the world's fastest NICs but the re(4) Realteks aren't *terrible* (and the driver is likely not as efficient as it could be.) rl(4) Realteks are *much* less good but people seem to apply Bill Paul's comments in *that* driver across to any nic made by the company... Also a ~5 year old celeron is not one to run 4xGbE full tilt in the first place (though it could be argued it will want any help it can get). > Your best bet for this would be a used quad-port Intel NIC, which can > be had for similar money (but not too much more) and is rather more > self-sufficient than the Realtek cards (and the maintainers of em(4) > are free to correct me there as well). You'll get better line > performance with less CPU stress. If the board has general problems with PCIE cards with bridges that might not fix the problem though. > On Thu, Oct 11, 2018 at 11:49 AM Martin Hanson > wrote: >> >> Hi, I have one of these 4-port Realtek NIC cards: >> https://www.ebay.co.uk/itm/PCIe-PCI-Express-to-4x-Gigabit-Card-4-Port-Ethernet-Network-Adapter-10-100-1000M/252484240577?epid=505371101 >> I >> am running OpenBSD 6.3 stable. During boot the card is seen, but it only >> works occasionally. When it works I can see all the 4 ports using >> "ifconfig" and I can assign IP addresses etc. When it doesn't work >> nothing is shown using "ifconfig". As far as I understand from the "re" >> manpage RTL8168E/8111E is supported. This is my dmesg: >> http://paste.debian.net/1046756/ When >> the card isn't working I also get this: +ppb1 at pci1 dev 0 function 0 It is preferable to just include the whole dmesg directly in the mail Better still, when it's a "sometimes works" problem, include a "diff -u" between the two (the context to show where the lines are added/removed). "pcidump -vxx" in both states might be useful too. (Ideally without non-ascii characters in the mail :-) >> vendor "ASMedia", unknown product 0x1184 rev 0x00 >> +pci2 at ppb1 bus 2 >> +ppb2 at pci2 dev 1 function 0 vendor "ASMedia", unknown product 0x1184 >> rev 0x00: not configured by system firmware >> +ppb3 at pci2 dev 3 function 0 vendor "ASMedia", unknown product 0x1184 >> rev 0x00: not configured by system firmware >> +ppb4 at pci2 dev 5 function 0 vendor "ASMedia", unknown product 0x1184 >> rev 0x00: not configured by system firmware >> +ppb5 at pci2 dev 7 function 0 vendor "ASMedia", unknown product 0x1184 >> rev 0x00: not configured by system firmware >>  Is this a driver issue or something else perhaps? Kindest regards Very unlikely to be a problem with the NIC driver. From what I've seen (and having seen other examples of the quality of Jetway's BIOSes) my money would be on a BIOS bug. Can you identify any particular situations where it works or fails? For example "works after a cold boot but not warm" or something? Personally if I had to use this hardware as a router I'd use a single port card (which will probably work OK) and break the ports out on a managed switch via vlans instead.
carppeer question
Hi, I have changed my CARP failover setup from default multicast to unicast by introducing carppeer config option. Physical interfaces share /29 subnet with upstream ISP, and IP addressing is as follows: ISP: XX.XXX.XXX.121/29 FW1: XX.XXX.XXX.122/29 FW2: XX.XXX.XXX.123/29 FW_CARP: XX.XXX.XXX.124/29 I am announcing my AS to ISP via BGP from both FW1 and FW2, using match rules to set $FW_CARP as nexthop address: match to $ISP set nexthop $FW_CARP After introducing carppeer option I see incoming traffic on physical interfaces of both MASTER and BACKUP firewalls, as opposed to the situation without carppeer option, where I see incoming traffic on physical interface of MASTER only. Here's hostname.carp3 of both firewalls: FW2 (MASTER): inet XX.XXX.XXX.124 255.255.255.248 NONE \ description ISP-CARP \ advskew 0 \ carpdev bge3 \ carppeer XX.XX.XXX.122 \ pass -OfCourseIChangedThis \ vhid 3 FW1 (BACKUP): inet XX.XXX.XXX.124 255.255.255.248 NONE \ description ISP-CARP \ advskew 100 \ carpdev em1 \ carppeer XX.XXX.XXX.123 \ pass -OfCourseIChangedThis \ vhid 3 Is this the intended behaviour? Or am I doing something wrong? By the way, I am moving to unicast CARP primarily because I heard that OSPF sessions in GRE tunnels that terminate on unicast CARP interfaces survive failovers, as opposed to my tests with default multicast CARP where OSPF gets confused after failover. I couldn't find much info on this, and I would be thankful if someone pointed me where to look or share their experiences. Thank you in advance, -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
