Re: c++: error: unknown argument: '-fno-ret-protector' when compiling CURRENT userland
Stuart, thank you so much for the info! > Your compiler is old (from 6.3 at a quick guess based on the date), > you either need to install a snapshot and move from there, or follow > http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/www/faq/current.html?rev=1.918&content-type=text/html#r20180606 I've been following this "usual" version of the above document only: https://www.openbsd.org/faq/current.html There, it doesn't say a thing about the change in the compiler. Human error? Thanks again, Stuart! Yours, Jyri
Re: DWA-131 Rev E
Thanks! Are there any plans to support this adapter? I'll donate my adapter if it would help. On Thu, Jul 5, 2018 at 8:35 PM Stuart Henderson wrote: > On 2018-07-05, Christopher Turkel wrote: > > Hi all I have a DWA-131 Rev E > > > > It (seems) to use a Realtek 8192eu. I googled and read mapages but I > > couldn't find an answer. > > > > I'm on OpenBSD/amd64 and running -current > > This isn't supported. See "man -k 802.11" for a list of most of the > available devices, and there is also bwfm(4) which needs a description > change in the manpage to get picked up with that search. > > >
Re: em0: couldn't map interrupt (No support for my Intel NIC?)
On Thu, Jul 05, 2018 at 06:49:30PM +0200, Farid Joubbi wrote: > Hi, > The Intel NIC works correctly in the native FreeBSD. I used it there before > I did the passthrough. > The Intel NIC worked correctly natively when I tested the OpenBSD installer. > The Intel NIC works in bhyve if I install FreeBSD. > > The new Broadcom NIC also works normally as long as it's not a OpenBSD > instance in bhyve. > > The NICs are not assigned to other hosts. > > The settings for virtualization on the hardware are correct to my knowledge. > I have several other hosts running in bhyve without problems. > One FreeBSD host using passthrough the same way as I intend to do with > OpenBSD. > I'd advise taking this to the FreeBSD lists, as you've already determined that without bhyve involved, things work as planned. -ml > > On Thu, Jul 5, 2018 at 4:55 PM Tom Smyth > wrote: > > > Hello Farid, > > > > > > Can you confirm that other operating systems pick up the Nic ok and > > they function ok > > > > has the Physical Host settings been setup correctly for SR-IOV > > > > is it possible that the nic has been assigned to another vm ? > > > > Hope this helps > > > > > > On 5 July 2018 at 15:38, Farid Joubbi wrote: > > > I realize now that I wrote a reply to only Mike and not the whole misc > > > earlier. > > > > > > Anyway. > > > The server is running several functions, and it's not popular to do > > > maintenance on it. > > > I went ahead and rebooted it anyway since this is important ;-) > > > > > > I booted the OpenBSD 6.3 install media natively on the hardware. > > > It found all six NICs that I have installed. There are two Broadcom on > > the > > > mainboard and four on the Intel card. > > > Broadcoms were found as bge and Intel as em. They all seemed to work. > > > > > > I had an extra bge card lying around. I installed it in the server and > > did > > > PCI passthrough with it as well as the Intel in FreeBSD/bhyve. > > > I get the same result in OpenBSD: > > > bge0 at pci0 dev 5 function 0 "Broadcom BCM5720" rev 0x00, BCM5720 A0 > > > (0x572), APE firmware NCSI 1.4.12.0: couldn't map interrupt > > > > > > Conclusion: > > > The problem has to do with the fact that bhyve is between the hardware > > and > > > OpenBSD. > > > > > > Any ideas? > > > > > > On Thu, Jul 5, 2018 at 2:31 AM Mike Larkin wrote: > > > > > >> On Thu, Jul 05, 2018 at 03:36:17AM +0200, Farid Joubbi wrote: > > >> > Hi, > > >> > > > >> > I have a server running bhyve in FreeBSD. I did PCI passthrough in > > order > > >> > to have exclusive access to one of the network interfaces on the > > server. > > >> > My plan was to use that NIC in OpenBSD. Unfortunately when I boot the > > 6.3 > > >> > release installer I get this in dmesg: > > >> > "em0 at pci0 dev 5 function 0 "Intel 82576" rev 0x01: couldn't map > > >> > interrupt". > > >> > > > >> > The installation goes through without errors, but the Intel NIC is not > > >> > visible during install or after rebooting the installed system. > > >> > > > >> > Man pages suggest that the problem is a fatal initialization error. > > >> > > > >> > The NIC works without problems installing FreeBSD. > > >> > In FreeBSD the NIC uses the igb driver. > > >> > > > >> > https://man.openbsd.org/FreeBSD-11.1/igb.4 > > >> > > > >> > The OpenBSD man page for em lists 82576EB as supported. > > >> > > > >> > The NIC is an Intel Gigabi ET2 quad: > > >> > > > >> > > https://ark.intel.com/products/series/46841/Intel-Gigabit-ET-Server-Adapter-Series > > >> > > > >> > Could it be that the quad variant of the NIC is not supported by > > OpenBSD? > > >> > Is there anything I can do to make it work? > > >> > Is it possible to use the igb driver in OpenBSD somehow? > > >> > > > >> > Thanks. > > >> > > >> Before anyone at all spends any time on this, please verify if this > > works > > >> without bhyve in the way. Eg, boot natively on this hardware and see. > > >> > > >> Or did you already do that? In which case the commentary about bhyve is > > >> extraneous. > > >> > > >> -ml > > >> > > > > > > > > -- > > Kindest regards, > > Tom Smyth > > > > Mobile: +353 87 6193172 > > The information contained in this E-mail is intended only for the > > confidential use of the named recipient. If the reader of this message > > is not the intended recipient or the person responsible for > > delivering it to the recipient, you are hereby notified that you have > > received this communication in error and that any review, > > dissemination or copying of this communication is strictly prohibited. > > If you have received this in error, please notify the sender > > immediately by telephone at the number above and erase the message > > You are requested to carry out your own virus check before > > opening any attachment. > >
Re: DWA-131 Rev E
On 2018-07-05, Christopher Turkel wrote: > Hi all I have a DWA-131 Rev E > > It (seems) to use a Realtek 8192eu. I googled and read mapages but I > couldn't find an answer. > > I'm on OpenBSD/amd64 and running -current This isn't supported. See "man -k 802.11" for a list of most of the available devices, and there is also bwfm(4) which needs a description change in the manpage to get picked up with that search.
DWA-131 Rev E
Hi all I have a DWA-131 Rev E It (seems) to use a Realtek 8192eu. I googled and read mapages but I couldn't find an answer. I'm on OpenBSD/amd64 and running -current *Dmesg:* OpenBSD 6.3-current (GENERIC.MP) #98: Thu Jul 5 12:52:45 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4180746240 (3987MB) avail mem = 4044902400 (3857MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (63 entries) bios0: vendor Apple Inc. version "MBP91.88Z.00D7.B00.1708080744" date 08/08/2017 bios0: Apple Inc. MacBookPro9,2 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT DMAR MCFG acpi0: wakeup devices P0P2(S3) PEG1(S3) EC__(S4) GMUX(S3) HDEF(S3) RP01(S3) GIGE(S3) SDXC(S3) RP02(S3) ARPT(S3) RP03(S3) EHC1(S3) EHC2(S3) XHC1(S3) ADP1(S4) LID0(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) i5-3210M CPU @ 2.50GHz, 2494.72 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,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,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 2 (application processor) cpu1: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.33 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,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,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.33 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,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,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.33 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,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,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 , remapped to apid 2 acpiec0 at acpi0 acpimcfg0 at acpi0 addr 0xe000, bus 0-154 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 4 (P0P2) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus 1 (RP01) acpiprt4 at acpi0: bus 2 (RP02) acpiprt5 at acpi0: bus 3 (RP03) acpicpu0 at acpi0: C3(200@198 mwait.1@0x30), C2(500@148 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@198 mwait.1@0x30), C2(500@148 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@198 mwait.1@0x30), C2(500@148 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(200@198 mwait.1@0x30), C2(500@148 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpisbs0 at acpi0: SBS0 model "bq20z451" serial 51234 type LION oem "DP" acpicmos0 at acpi0 "APP0001" at acpi0 not configured "APP0003" at acpi0 not configured "ACPI0008" at acpi0 not configured "ACPI0001" at acpi0 not configured "APP000B" at acpi0 not configured acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PWRB "APP0002" at acpi0 not configured acpibtn2 at acpi0: SLPB acpivideo0 at acpi0: IGPU acpivout0 at acpivideo0: DD02 cpu0: Enhanced SpeedStep 2494 MHz: speeds: 2501, 2500, 2400, 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200 MHz memory map conflict 0xe00f8000/0x1000 memory map conflict 0xfed1c000/0x4000 memory map conflict 0xffe7/0x3 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09 ppb0 at pci0 dev 1 function 0 "Intel Core 3G PCIE" rev 0x09: msi pci1 at ppb0 bus 4 ppb1 at pci1 dev 0 function 0 "Intel 82524EF Thunderbolt" rev 0x00 p
Re: em0: couldn't map interrupt (No support for my Intel NIC?)
NetBSD does not work either. I get the exact same error as with OpenBSD. CentOS works fine. On Thu, Jul 5, 2018 at 10:20 PM Farid Joubbi wrote: > I am running several virtual machines on top of bhyve. I've got FreeBSD, > RHEL, Linux Mint and Debian running now. > I have tried OpenBSD without a passthrough NIC and CentOS. > > > On Thu, Jul 5, 2018, 20:14 Tom Smyth wrote: > >> Farid >> Can you check if the SR-IOV works by runing another OS as a vm on top of >> Bhyve on the host >> >> that is what I meant on my previous mail >> Thanks >> >> On 5 July 2018 at 17:49, Farid Joubbi wrote: >> > Hi, >> > The Intel NIC works correctly in the native FreeBSD. I used it there >> before >> > I did the passthrough. >> > The Intel NIC worked correctly natively when I tested the OpenBSD >> installer. >> > The Intel NIC works in bhyve if I install FreeBSD. >> > >> > The new Broadcom NIC also works normally as long as it's not a OpenBSD >> > instance in bhyve. >> > >> > The NICs are not assigned to other hosts. >> > >> > The settings for virtualization on the hardware are correct to my >> knowledge. >> > I have several other hosts running in bhyve without problems. >> > One FreeBSD host using passthrough the same way as I intend to do with >> > OpenBSD. >> > >> > >> > On Thu, Jul 5, 2018 at 4:55 PM Tom Smyth >> > wrote: >> >> >> >> Hello Farid, >> >> >> >> >> >> Can you confirm that other operating systems pick up the Nic ok and >> >> they function ok >> >> >> >> has the Physical Host settings been setup correctly for SR-IOV >> >> >> >> is it possible that the nic has been assigned to another vm ? >> >> >> >> Hope this helps >> >> >> >> >> >> On 5 July 2018 at 15:38, Farid Joubbi wrote: >> >> > I realize now that I wrote a reply to only Mike and not the whole >> misc >> >> > earlier. >> >> > >> >> > Anyway. >> >> > The server is running several functions, and it's not popular to do >> >> > maintenance on it. >> >> > I went ahead and rebooted it anyway since this is important ;-) >> >> > >> >> > I booted the OpenBSD 6.3 install media natively on the hardware. >> >> > It found all six NICs that I have installed. There are two Broadcom >> on >> >> > the >> >> > mainboard and four on the Intel card. >> >> > Broadcoms were found as bge and Intel as em. They all seemed to work. >> >> > >> >> > I had an extra bge card lying around. I installed it in the server >> and >> >> > did >> >> > PCI passthrough with it as well as the Intel in FreeBSD/bhyve. >> >> > I get the same result in OpenBSD: >> >> > bge0 at pci0 dev 5 function 0 "Broadcom BCM5720" rev 0x00, BCM5720 A0 >> >> > (0x572), APE firmware NCSI 1.4.12.0: couldn't map interrupt >> >> > >> >> > Conclusion: >> >> > The problem has to do with the fact that bhyve is between the >> hardware >> >> > and >> >> > OpenBSD. >> >> > >> >> > Any ideas? >> >> > >> >> > On Thu, Jul 5, 2018 at 2:31 AM Mike Larkin >> wrote: >> >> > >> >> >> On Thu, Jul 05, 2018 at 03:36:17AM +0200, Farid Joubbi wrote: >> >> >> > Hi, >> >> >> > >> >> >> > I have a server running bhyve in FreeBSD. I did PCI passthrough >> in >> >> >> > order >> >> >> > to have exclusive access to one of the network interfaces on the >> >> >> > server. >> >> >> > My plan was to use that NIC in OpenBSD. Unfortunately when I boot >> the >> >> >> > 6.3 >> >> >> > release installer I get this in dmesg: >> >> >> > "em0 at pci0 dev 5 function 0 "Intel 82576" rev 0x01: couldn't map >> >> >> > interrupt". >> >> >> > >> >> >> > The installation goes through without errors, but the Intel NIC is >> >> >> > not >> >> >> > visible during install or after rebooting the installed system. >> >> >> > >> >> >> > Man pages suggest that the problem is a fatal initialization >> error. >> >> >> > >> >> >> > The NIC works without problems installing FreeBSD. >> >> >> > In FreeBSD the NIC uses the igb driver. >> >> >> > >> >> >> > https://man.openbsd.org/FreeBSD-11.1/igb.4 >> >> >> > >> >> >> > The OpenBSD man page for em lists 82576EB as supported. >> >> >> > >> >> >> > The NIC is an Intel Gigabi ET2 quad: >> >> >> > >> >> >> >> >> >> >> https://ark.intel.com/products/series/46841/Intel-Gigabit-ET-Server-Adapter-Series >> >> >> > >> >> >> > Could it be that the quad variant of the NIC is not supported by >> >> >> > OpenBSD? >> >> >> > Is there anything I can do to make it work? >> >> >> > Is it possible to use the igb driver in OpenBSD somehow? >> >> >> > >> >> >> > Thanks. >> >> >> >> >> >> Before anyone at all spends any time on this, please verify if this >> >> >> works >> >> >> without bhyve in the way. Eg, boot natively on this hardware and >> see. >> >> >> >> >> >> Or did you already do that? In which case the commentary about >> bhyve is >> >> >> extraneous. >> >> >> >> >> >> -ml >> >> >> >> >> >> >> >> >> >> >> -- >> >> Kindest regards, >> >> Tom Smyth >> >> >> >> Mobile: +353 87 6193172 >> >> The information contained in this E-mail is intended only for the >> >> confidential use of the named recipient. If the reader of this m
Re: em0: couldn't map interrupt (No support for my Intel NIC?)
I am running several virtual machines on top of bhyve. I've got FreeBSD, RHEL, Linux Mint and Debian running now. I have tried OpenBSD without a passthrough NIC and CentOS. On Thu, Jul 5, 2018, 20:14 Tom Smyth wrote: > Farid > Can you check if the SR-IOV works by runing another OS as a vm on top of > Bhyve on the host > > that is what I meant on my previous mail > Thanks > > On 5 July 2018 at 17:49, Farid Joubbi wrote: > > Hi, > > The Intel NIC works correctly in the native FreeBSD. I used it there > before > > I did the passthrough. > > The Intel NIC worked correctly natively when I tested the OpenBSD > installer. > > The Intel NIC works in bhyve if I install FreeBSD. > > > > The new Broadcom NIC also works normally as long as it's not a OpenBSD > > instance in bhyve. > > > > The NICs are not assigned to other hosts. > > > > The settings for virtualization on the hardware are correct to my > knowledge. > > I have several other hosts running in bhyve without problems. > > One FreeBSD host using passthrough the same way as I intend to do with > > OpenBSD. > > > > > > On Thu, Jul 5, 2018 at 4:55 PM Tom Smyth > > wrote: > >> > >> Hello Farid, > >> > >> > >> Can you confirm that other operating systems pick up the Nic ok and > >> they function ok > >> > >> has the Physical Host settings been setup correctly for SR-IOV > >> > >> is it possible that the nic has been assigned to another vm ? > >> > >> Hope this helps > >> > >> > >> On 5 July 2018 at 15:38, Farid Joubbi wrote: > >> > I realize now that I wrote a reply to only Mike and not the whole misc > >> > earlier. > >> > > >> > Anyway. > >> > The server is running several functions, and it's not popular to do > >> > maintenance on it. > >> > I went ahead and rebooted it anyway since this is important ;-) > >> > > >> > I booted the OpenBSD 6.3 install media natively on the hardware. > >> > It found all six NICs that I have installed. There are two Broadcom on > >> > the > >> > mainboard and four on the Intel card. > >> > Broadcoms were found as bge and Intel as em. They all seemed to work. > >> > > >> > I had an extra bge card lying around. I installed it in the server and > >> > did > >> > PCI passthrough with it as well as the Intel in FreeBSD/bhyve. > >> > I get the same result in OpenBSD: > >> > bge0 at pci0 dev 5 function 0 "Broadcom BCM5720" rev 0x00, BCM5720 A0 > >> > (0x572), APE firmware NCSI 1.4.12.0: couldn't map interrupt > >> > > >> > Conclusion: > >> > The problem has to do with the fact that bhyve is between the hardware > >> > and > >> > OpenBSD. > >> > > >> > Any ideas? > >> > > >> > On Thu, Jul 5, 2018 at 2:31 AM Mike Larkin > wrote: > >> > > >> >> On Thu, Jul 05, 2018 at 03:36:17AM +0200, Farid Joubbi wrote: > >> >> > Hi, > >> >> > > >> >> > I have a server running bhyve in FreeBSD. I did PCI passthrough in > >> >> > order > >> >> > to have exclusive access to one of the network interfaces on the > >> >> > server. > >> >> > My plan was to use that NIC in OpenBSD. Unfortunately when I boot > the > >> >> > 6.3 > >> >> > release installer I get this in dmesg: > >> >> > "em0 at pci0 dev 5 function 0 "Intel 82576" rev 0x01: couldn't map > >> >> > interrupt". > >> >> > > >> >> > The installation goes through without errors, but the Intel NIC is > >> >> > not > >> >> > visible during install or after rebooting the installed system. > >> >> > > >> >> > Man pages suggest that the problem is a fatal initialization error. > >> >> > > >> >> > The NIC works without problems installing FreeBSD. > >> >> > In FreeBSD the NIC uses the igb driver. > >> >> > > >> >> > https://man.openbsd.org/FreeBSD-11.1/igb.4 > >> >> > > >> >> > The OpenBSD man page for em lists 82576EB as supported. > >> >> > > >> >> > The NIC is an Intel Gigabi ET2 quad: > >> >> > > >> >> > >> >> > https://ark.intel.com/products/series/46841/Intel-Gigabit-ET-Server-Adapter-Series > >> >> > > >> >> > Could it be that the quad variant of the NIC is not supported by > >> >> > OpenBSD? > >> >> > Is there anything I can do to make it work? > >> >> > Is it possible to use the igb driver in OpenBSD somehow? > >> >> > > >> >> > Thanks. > >> >> > >> >> Before anyone at all spends any time on this, please verify if this > >> >> works > >> >> without bhyve in the way. Eg, boot natively on this hardware and see. > >> >> > >> >> Or did you already do that? In which case the commentary about bhyve > is > >> >> extraneous. > >> >> > >> >> -ml > >> >> > >> > >> > >> > >> -- > >> Kindest regards, > >> Tom Smyth > >> > >> Mobile: +353 87 6193172 > >> The information contained in this E-mail is intended only for the > >> confidential use of the named recipient. If the reader of this message > >> is not the intended recipient or the person responsible for > >> delivering it to the recipient, you are hereby notified that you have > >> received this communication in error and that any review, > >> dissemination or copying of this communication is strictly prohibited. > >> If you have received this
c++: error: unknown argument: '-fno-ret-protector' when compiling CURRENT userland
Hi! Been following CURRENT for quite a while, experiencing zero problems. However, now there's a problem compiling the 64-bit CURRENT on two servers -- one virtual, one full iron. OpenBSD 6.3-current (GENERIC.MP) #19: Thu Jul 5 12:23:55 UTC 2018 ***@***.turvamies.fi:/sys/arch/amd64/compile/GENERIC.MP # cd /usr/src # make obj => everyhing good # make build => results in: ... ===> gnu/usr.bin/clang ===> gnu/usr.bin/clang/include/llvm/Config printf "LLVM_ASM_PARSER(X86)\n#undef LLVM_ASM_PARSER\n" >AsmParsers.def printf "LLVM_ASM_PRINTER(X86)\n#undef LLVM_ASM_PRINTER\n" >AsmPrinters.def printf "LLVM_DISASSEMBLER(X86)\n#undef LLVM_DISASSEMBLER\n" >Disassemblers.def printf "LLVM_TARGET(X86)\n#undef LLVM_TARGET\n" >Targets.def ===> gnu/usr.bin/clang/libLLVMSupport c++ -O2 -pipe -std=c++11 -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wdelete-non-virtual-dtor -Wno-comment -fno-pie -MD -MP -I/usr/src/gnu/usr.bin/clang/libLLVMSupport/../../../llvm/include/llvm/Support -I/usr/src/gnu/usr.bin/clang/libLLVMSupport/../../../llvm/include -I/usr/src/gnu/usr.bin/clang/libLLVMSupport/../include -I/usr/src/gnu/usr.bin/clang/libLLVMSupport/obj -I/usr/src/gnu/usr.bin/clang/libLLVMSupport/obj/../include -DNDEBUG -fno-ret-protector -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE="amd64-unknown-openbsd6.3" -DLLVM_HOST_TRIPLE="amd64-unknown-openbsd6.3" -DLLVM_PREFIX="/usr" -DLLVM_NATIVE_ARCH="X86" -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler -DLLVM_NATIVE_TARGET=LLVMInitializeX86Target -DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -c /usr/src/gnu/usr.bin/clang/libLLVMSupport/../../../llvm/lib/Support/APFloat.cpp -o APFloat.o c++: error: unknown argument: '-fno-ret-protector' *** Error 1 in gnu/usr.bin/clang/libLLVMSupport (:69 'APFloat.o': @c++ -O2 -pipe -std=c++11 -fvisibility-inlines-hidden -fno-ex...) *** Error 1 in gnu/usr.bin/clang (:48 'all') *** Error 1 in gnu/usr.bin (:48 'all') *** Error 1 in gnu (:48 'all') *** Error 1 in . (:48 'all') *** Error 1 in . (Makefile:95 'do-build') *** Error 1 in /usr/src (Makefile:74 'build') # c++ -v OpenBSD clang version 6.0.0 (tags/RELEASE_600/final) (based on LLVM 6.0.0) Target: amd64-unknown-openbsd6.3 Thread model: posix InstalledDir: /usr/bin # ls -la /usr/bin/c++* -r-xr-xr-x 6 root bin 46453496 Apr 25 10:10 /usr/bin/c++ -r-xr-xr-x 1 root bin 10008 Apr 25 10:10 /usr/bin/c++filt # /usr/bin/c++ -v OpenBSD clang version 6.0.0 (tags/RELEASE_600/final) (based on LLVM 6.0.0) Target: amd64-unknown-openbsd6.3 Thread model: posix InstalledDir: /usr/bin Can't figure out what's wrong. Do I have an outdated version of c++ in the system for some reason? Yours, Jyri -- jyri.hov...@iki.fi +358-404-177133 (24/7)
Re: em0: couldn't map interrupt (No support for my Intel NIC?)
Farid Can you check if the SR-IOV works by runing another OS as a vm on top of Bhyve on the host that is what I meant on my previous mail Thanks On 5 July 2018 at 17:49, Farid Joubbi wrote: > Hi, > The Intel NIC works correctly in the native FreeBSD. I used it there before > I did the passthrough. > The Intel NIC worked correctly natively when I tested the OpenBSD installer. > The Intel NIC works in bhyve if I install FreeBSD. > > The new Broadcom NIC also works normally as long as it's not a OpenBSD > instance in bhyve. > > The NICs are not assigned to other hosts. > > The settings for virtualization on the hardware are correct to my knowledge. > I have several other hosts running in bhyve without problems. > One FreeBSD host using passthrough the same way as I intend to do with > OpenBSD. > > > On Thu, Jul 5, 2018 at 4:55 PM Tom Smyth > wrote: >> >> Hello Farid, >> >> >> Can you confirm that other operating systems pick up the Nic ok and >> they function ok >> >> has the Physical Host settings been setup correctly for SR-IOV >> >> is it possible that the nic has been assigned to another vm ? >> >> Hope this helps >> >> >> On 5 July 2018 at 15:38, Farid Joubbi wrote: >> > I realize now that I wrote a reply to only Mike and not the whole misc >> > earlier. >> > >> > Anyway. >> > The server is running several functions, and it's not popular to do >> > maintenance on it. >> > I went ahead and rebooted it anyway since this is important ;-) >> > >> > I booted the OpenBSD 6.3 install media natively on the hardware. >> > It found all six NICs that I have installed. There are two Broadcom on >> > the >> > mainboard and four on the Intel card. >> > Broadcoms were found as bge and Intel as em. They all seemed to work. >> > >> > I had an extra bge card lying around. I installed it in the server and >> > did >> > PCI passthrough with it as well as the Intel in FreeBSD/bhyve. >> > I get the same result in OpenBSD: >> > bge0 at pci0 dev 5 function 0 "Broadcom BCM5720" rev 0x00, BCM5720 A0 >> > (0x572), APE firmware NCSI 1.4.12.0: couldn't map interrupt >> > >> > Conclusion: >> > The problem has to do with the fact that bhyve is between the hardware >> > and >> > OpenBSD. >> > >> > Any ideas? >> > >> > On Thu, Jul 5, 2018 at 2:31 AM Mike Larkin wrote: >> > >> >> On Thu, Jul 05, 2018 at 03:36:17AM +0200, Farid Joubbi wrote: >> >> > Hi, >> >> > >> >> > I have a server running bhyve in FreeBSD. I did PCI passthrough in >> >> > order >> >> > to have exclusive access to one of the network interfaces on the >> >> > server. >> >> > My plan was to use that NIC in OpenBSD. Unfortunately when I boot the >> >> > 6.3 >> >> > release installer I get this in dmesg: >> >> > "em0 at pci0 dev 5 function 0 "Intel 82576" rev 0x01: couldn't map >> >> > interrupt". >> >> > >> >> > The installation goes through without errors, but the Intel NIC is >> >> > not >> >> > visible during install or after rebooting the installed system. >> >> > >> >> > Man pages suggest that the problem is a fatal initialization error. >> >> > >> >> > The NIC works without problems installing FreeBSD. >> >> > In FreeBSD the NIC uses the igb driver. >> >> > >> >> > https://man.openbsd.org/FreeBSD-11.1/igb.4 >> >> > >> >> > The OpenBSD man page for em lists 82576EB as supported. >> >> > >> >> > The NIC is an Intel Gigabi ET2 quad: >> >> > >> >> >> >> https://ark.intel.com/products/series/46841/Intel-Gigabit-ET-Server-Adapter-Series >> >> > >> >> > Could it be that the quad variant of the NIC is not supported by >> >> > OpenBSD? >> >> > Is there anything I can do to make it work? >> >> > Is it possible to use the igb driver in OpenBSD somehow? >> >> > >> >> > Thanks. >> >> >> >> Before anyone at all spends any time on this, please verify if this >> >> works >> >> without bhyve in the way. Eg, boot natively on this hardware and see. >> >> >> >> Or did you already do that? In which case the commentary about bhyve is >> >> extraneous. >> >> >> >> -ml >> >> >> >> >> >> -- >> Kindest regards, >> Tom Smyth >> >> Mobile: +353 87 6193172 >> The information contained in this E-mail is intended only for the >> confidential use of the named recipient. If the reader of this message >> is not the intended recipient or the person responsible for >> delivering it to the recipient, you are hereby notified that you have >> received this communication in error and that any review, >> dissemination or copying of this communication is strictly prohibited. >> If you have received this in error, please notify the sender >> immediately by telephone at the number above and erase the message >> You are requested to carry out your own virus check before >> opening any attachment. -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby not
Re: How to configure address selection policy for IPv6 (and IPv4)
On 2018-07-04, Gerlach, Hendrik wrote: > Hello, > > according to RFC3484 and it's successor (RFC6724) a IPv6 implementation > should support a configurable address selection via a mechanism at least as > powerful as the policy table defines in this RFC's. > > Found the powerful ip6addrctl command in Freebsd (derived from KAME's > addrselect) , but it seem's that there is no such command for OpenBSD. > > My Questions: > 1. Is there some possibility to show and manipulate the address selection > policy in OpenBSD ? > 2. if not: are there any plans to implement this in the near future ? > 3. If not: is the kernel internal address selection policy conform to the > default address selection policy in RFC6724 ? > > Thanks, > Hendrik > > There's no general way to do this in OpenBSD. It's not what you're asking for but in some circumstances you may be able to workaround this - if you have certain addresses configured that you do not want to use as a source address you can set the address with "pltime 0".
Re: em0: couldn't map interrupt (No support for my Intel NIC?)
Hi, The Intel NIC works correctly in the native FreeBSD. I used it there before I did the passthrough. The Intel NIC worked correctly natively when I tested the OpenBSD installer. The Intel NIC works in bhyve if I install FreeBSD. The new Broadcom NIC also works normally as long as it's not a OpenBSD instance in bhyve. The NICs are not assigned to other hosts. The settings for virtualization on the hardware are correct to my knowledge. I have several other hosts running in bhyve without problems. One FreeBSD host using passthrough the same way as I intend to do with OpenBSD. On Thu, Jul 5, 2018 at 4:55 PM Tom Smyth wrote: > Hello Farid, > > > Can you confirm that other operating systems pick up the Nic ok and > they function ok > > has the Physical Host settings been setup correctly for SR-IOV > > is it possible that the nic has been assigned to another vm ? > > Hope this helps > > > On 5 July 2018 at 15:38, Farid Joubbi wrote: > > I realize now that I wrote a reply to only Mike and not the whole misc > > earlier. > > > > Anyway. > > The server is running several functions, and it's not popular to do > > maintenance on it. > > I went ahead and rebooted it anyway since this is important ;-) > > > > I booted the OpenBSD 6.3 install media natively on the hardware. > > It found all six NICs that I have installed. There are two Broadcom on > the > > mainboard and four on the Intel card. > > Broadcoms were found as bge and Intel as em. They all seemed to work. > > > > I had an extra bge card lying around. I installed it in the server and > did > > PCI passthrough with it as well as the Intel in FreeBSD/bhyve. > > I get the same result in OpenBSD: > > bge0 at pci0 dev 5 function 0 "Broadcom BCM5720" rev 0x00, BCM5720 A0 > > (0x572), APE firmware NCSI 1.4.12.0: couldn't map interrupt > > > > Conclusion: > > The problem has to do with the fact that bhyve is between the hardware > and > > OpenBSD. > > > > Any ideas? > > > > On Thu, Jul 5, 2018 at 2:31 AM Mike Larkin wrote: > > > >> On Thu, Jul 05, 2018 at 03:36:17AM +0200, Farid Joubbi wrote: > >> > Hi, > >> > > >> > I have a server running bhyve in FreeBSD. I did PCI passthrough in > order > >> > to have exclusive access to one of the network interfaces on the > server. > >> > My plan was to use that NIC in OpenBSD. Unfortunately when I boot the > 6.3 > >> > release installer I get this in dmesg: > >> > "em0 at pci0 dev 5 function 0 "Intel 82576" rev 0x01: couldn't map > >> > interrupt". > >> > > >> > The installation goes through without errors, but the Intel NIC is not > >> > visible during install or after rebooting the installed system. > >> > > >> > Man pages suggest that the problem is a fatal initialization error. > >> > > >> > The NIC works without problems installing FreeBSD. > >> > In FreeBSD the NIC uses the igb driver. > >> > > >> > https://man.openbsd.org/FreeBSD-11.1/igb.4 > >> > > >> > The OpenBSD man page for em lists 82576EB as supported. > >> > > >> > The NIC is an Intel Gigabi ET2 quad: > >> > > >> > https://ark.intel.com/products/series/46841/Intel-Gigabit-ET-Server-Adapter-Series > >> > > >> > Could it be that the quad variant of the NIC is not supported by > OpenBSD? > >> > Is there anything I can do to make it work? > >> > Is it possible to use the igb driver in OpenBSD somehow? > >> > > >> > Thanks. > >> > >> Before anyone at all spends any time on this, please verify if this > works > >> without bhyve in the way. Eg, boot natively on this hardware and see. > >> > >> Or did you already do that? In which case the commentary about bhyve is > >> extraneous. > >> > >> -ml > >> > > > > -- > Kindest regards, > Tom Smyth > > Mobile: +353 87 6193172 > The information contained in this E-mail is intended only for the > confidential use of the named recipient. If the reader of this message > is not the intended recipient or the person responsible for > delivering it to the recipient, you are hereby notified that you have > received this communication in error and that any review, > dissemination or copying of this communication is strictly prohibited. > If you have received this in error, please notify the sender > immediately by telephone at the number above and erase the message > You are requested to carry out your own virus check before > opening any attachment. >
Re: em0: couldn't map interrupt (No support for my Intel NIC?)
Hello Farid, Can you confirm that other operating systems pick up the Nic ok and they function ok has the Physical Host settings been setup correctly for SR-IOV is it possible that the nic has been assigned to another vm ? Hope this helps On 5 July 2018 at 15:38, Farid Joubbi wrote: > I realize now that I wrote a reply to only Mike and not the whole misc > earlier. > > Anyway. > The server is running several functions, and it's not popular to do > maintenance on it. > I went ahead and rebooted it anyway since this is important ;-) > > I booted the OpenBSD 6.3 install media natively on the hardware. > It found all six NICs that I have installed. There are two Broadcom on the > mainboard and four on the Intel card. > Broadcoms were found as bge and Intel as em. They all seemed to work. > > I had an extra bge card lying around. I installed it in the server and did > PCI passthrough with it as well as the Intel in FreeBSD/bhyve. > I get the same result in OpenBSD: > bge0 at pci0 dev 5 function 0 "Broadcom BCM5720" rev 0x00, BCM5720 A0 > (0x572), APE firmware NCSI 1.4.12.0: couldn't map interrupt > > Conclusion: > The problem has to do with the fact that bhyve is between the hardware and > OpenBSD. > > Any ideas? > > On Thu, Jul 5, 2018 at 2:31 AM Mike Larkin wrote: > >> On Thu, Jul 05, 2018 at 03:36:17AM +0200, Farid Joubbi wrote: >> > Hi, >> > >> > I have a server running bhyve in FreeBSD. I did PCI passthrough in order >> > to have exclusive access to one of the network interfaces on the server. >> > My plan was to use that NIC in OpenBSD. Unfortunately when I boot the 6.3 >> > release installer I get this in dmesg: >> > "em0 at pci0 dev 5 function 0 "Intel 82576" rev 0x01: couldn't map >> > interrupt". >> > >> > The installation goes through without errors, but the Intel NIC is not >> > visible during install or after rebooting the installed system. >> > >> > Man pages suggest that the problem is a fatal initialization error. >> > >> > The NIC works without problems installing FreeBSD. >> > In FreeBSD the NIC uses the igb driver. >> > >> > https://man.openbsd.org/FreeBSD-11.1/igb.4 >> > >> > The OpenBSD man page for em lists 82576EB as supported. >> > >> > The NIC is an Intel Gigabi ET2 quad: >> > >> https://ark.intel.com/products/series/46841/Intel-Gigabit-ET-Server-Adapter-Series >> > >> > Could it be that the quad variant of the NIC is not supported by OpenBSD? >> > Is there anything I can do to make it work? >> > Is it possible to use the igb driver in OpenBSD somehow? >> > >> > Thanks. >> >> Before anyone at all spends any time on this, please verify if this works >> without bhyve in the way. Eg, boot natively on this hardware and see. >> >> Or did you already do that? In which case the commentary about bhyve is >> extraneous. >> >> -ml >> -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Re: em0: couldn't map interrupt (No support for my Intel NIC?)
I realize now that I wrote a reply to only Mike and not the whole misc earlier. Anyway. The server is running several functions, and it's not popular to do maintenance on it. I went ahead and rebooted it anyway since this is important ;-) I booted the OpenBSD 6.3 install media natively on the hardware. It found all six NICs that I have installed. There are two Broadcom on the mainboard and four on the Intel card. Broadcoms were found as bge and Intel as em. They all seemed to work. I had an extra bge card lying around. I installed it in the server and did PCI passthrough with it as well as the Intel in FreeBSD/bhyve. I get the same result in OpenBSD: bge0 at pci0 dev 5 function 0 "Broadcom BCM5720" rev 0x00, BCM5720 A0 (0x572), APE firmware NCSI 1.4.12.0: couldn't map interrupt Conclusion: The problem has to do with the fact that bhyve is between the hardware and OpenBSD. Any ideas? On Thu, Jul 5, 2018 at 2:31 AM Mike Larkin wrote: > On Thu, Jul 05, 2018 at 03:36:17AM +0200, Farid Joubbi wrote: > > Hi, > > > > I have a server running bhyve in FreeBSD. I did PCI passthrough in order > > to have exclusive access to one of the network interfaces on the server. > > My plan was to use that NIC in OpenBSD. Unfortunately when I boot the 6.3 > > release installer I get this in dmesg: > > "em0 at pci0 dev 5 function 0 "Intel 82576" rev 0x01: couldn't map > > interrupt". > > > > The installation goes through without errors, but the Intel NIC is not > > visible during install or after rebooting the installed system. > > > > Man pages suggest that the problem is a fatal initialization error. > > > > The NIC works without problems installing FreeBSD. > > In FreeBSD the NIC uses the igb driver. > > > > https://man.openbsd.org/FreeBSD-11.1/igb.4 > > > > The OpenBSD man page for em lists 82576EB as supported. > > > > The NIC is an Intel Gigabi ET2 quad: > > > https://ark.intel.com/products/series/46841/Intel-Gigabit-ET-Server-Adapter-Series > > > > Could it be that the quad variant of the NIC is not supported by OpenBSD? > > Is there anything I can do to make it work? > > Is it possible to use the igb driver in OpenBSD somehow? > > > > Thanks. > > Before anyone at all spends any time on this, please verify if this works > without bhyve in the way. Eg, boot natively on this hardware and see. > > Or did you already do that? In which case the commentary about bhyve is > extraneous. > > -ml >
