Re: cpu cores
Greetings, On Mon, 10 Jun 2024 13:15:13 +0100, Riccardo Mottola wrote: > > This is for workstation use, mixed user and developer. To each its own. > I bet it ends depending also on cache, memory and specific jobs. > Do not forget about IO, which can be a bottel neck in case of compiling. Have you tried to run compilation with the same parallerism with and without HT enabled? For example build kernel with -j10 which is bigger than number of CPU with enabled HT on that machine (4 / 8): without HT: 8m42.07s real27m31.80s user 4m55.68s system vs with HT: 8m38.82s real50m47.22s user 8m41.53s system -- wbr, Kirill
Re: cpu cores
> > You've been on these lists for over 15 years and yet didn't include a > > complete dmesg. Ok. On Jun 09 22:31:02, rios.gust...@gmail.com wrote: > here it goes! > Stuart Henderson wrote: > > dmesg | grep smt will make it obvious. cpu0: smt 0, core 0, package 0 cpu1: smt 1, core 0, package 0 cpu2: smt 0, core 4, package 0 cpu3: smt 1, core 4, package 0 cpu4: smt 0, core 8, package 0 cpu5: smt 0, core 9, package 0 cpu6: smt 0, core 10, package 0 cpu7: smt 0, core 11, package 0
Re: cpu cores
Hi, Kirill A. Korinsky wrote: Thus, here old but interesting results that enabling hyperthreading has negative effect on performance of have CPU used applications: https://web.archive.org/web/20220325090914/http://users.telenet.be/nicvroom/performanceP4.htm there are many different experiences on Threading - HT. I started checking when it was disabled on my i5 and then I re-enabled it on OpenBSD. Same fate on NetBSD. I can say that for compiling bit packages where you can run senveral make jobs - as long as you have enough memory "per core", HT gives a great benefit. It gives also benefit if you compile say "n-1" threads and want to use your system as a desktop and it gives also definitive benefit in an average desktop where you want to browse, have a couple tabs open, check mail and run a terminal. This is more subjective, while diminishing compilation times are real. This is for workstation use, mixed user and developer. To each its own. I bet it ends depending also on cache, memory and specific jobs. I also read of cases where performance is abysmal and worse with more HT. And there are all the known security issues too. Riccardo
Re: cpu cores
Hi Stuartd, Stuart Henderson wrote: Exactly. dmesg | grep smt will make it obvious. The cache information for each attached cpu will probably also show differences between the P and E cores. Spec of the CPU listed in dmesg https://ark.intel.com/content/www/us/en/ark/products/226269/intel-core-i3-1215u-processor-10m-cache-up-to-4-40-ghz-with-ipu.html?countrylabel=Latin It is given as 6 core cpu, 8 threads. Riccardo
Re: cpu cores
here it goes! Em sáb., 8 de jun. de 2024 às 04:30, Philip Guenther escreveu: > On Fri, Jun 7, 2024 at 10:58 PM Gustavo Rios > wrote: > > i have installed obsd on my dell notebook 8 cores processor. When i > execute the top utility, it is showed the cores, from 0 (cpu0) to 7 (cpu7), > but cpu1 and cpu3 is not listed. What is the problem ? > > You've been on these lists for over 15 years and yet didn't include a > complete dmesg. Ok. > > If your dmesg completely lacks lines for cpu1 and cpu3 (but not 2 or 4 > or 5) then it's a limitation of that exact model and how the BIOS has > it configured. > > But that's really bizarre. Too bad we have zero information about > your laptop and the cpus inside it. > > > Philip Guenther > -- The lion and the tiger may be more powerful, but the wolves do not perform in the circus OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 MDT 2024 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8242978816 (7861MB) avail mem = 7972089856 (7602MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.4 @ 0x5d033000 (75 entries) bios0: vendor Dell Inc. version "1.16.0" date 06/20/2023 bios0: Dell Inc. Inspiron 15 3520 efi0 at bios0: UEFI 2.7 efi0: Dell rev 0x1 acpi0 at bios0: ACPI 6.3 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT HPET APIC MCFG SSDT SSDT SSDT NHLT SSDT LPIT SSDT SSDT DBGP DBG2 BOOT MSDM SSDT TPM2 DMAR SSDT SSDT SSDT SSDT PHAT BGRT FPDT acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEG2(S4) PEGP(S4) XHCI(S0) XDCI(S4) HDAS(S4) CNVW(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: 12th Gen Intel(R) Core(TM) i3-1215U, 4390.68 MHz, 06-9a-04, patch 042a 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,WAITPKG,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,TAA_NO,MISC_PKG_CT,ENERGY_FILT,DOITM,SBDR_SSDP_N,FBSDP_NO,PSDP_NO,RRSBA,OVERCLOCK,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 10-way L2 cache, 10MB 64b/line 10-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 38MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2.0.1.0.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: 12th Gen Intel(R) Core(TM) i3-1215U, 4390.69 MHz, 06-9a-04, patch 042a 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,WAITPKG,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,TAA_NO,MISC_PKG_CT,ENERGY_FILT,DOITM,SBDR_SSDP_N,FBSDP_NO,PSDP_NO,RRSBA,OVERCLOCK,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 10-way L2 cache, 10MB 64b/line 10-way L3 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 8 (application processor) cpu2: 12th Gen Intel(R) Core(TM) i3-1215U, 3991.51 MHz, 06-9a-04, patch 042a 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,WAITPKG,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,TAA_NO,MISC_PKG_CT,ENERGY_FILT,DOITM,SBDR_SSDP_N,FBSDP_NO,PSDP_NO,RRSBA,OVERCLOCK,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 10-way L2 cache, 10MB 64b/line 10-way L3 cache cpu2: smt 0, core 4, package 0 cpu3 at mainbus0: apid 9 (application processor) cpu3: 12th Gen Intel(R) Core(TM) i3-1215U, 3991.51 MHz, 06-9a-04, patch 042a cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI
Re: cpu cores
On 2024-06-08, Otto Moerbeek wrote: > On Sat, Jun 08, 2024 at 03:58:30PM +0200, Andreas Kähäri wrote: > >> Not knowing too much about these things, I think it looks a bit strange >> that *two* out of eight CPUs are disabled due to hypethreading. I would >> have expected every second one be disabled, i.e., four out of eight. > > This simple rule does not apply to more modern CPUs, which can have > different types of cores, some with hyperthreading and some without. Exactly. dmesg | grep smt will make it obvious. The cache information for each attached cpu will probably also show differences between the P and E cores. -- Please keep replies on the mailing list.
Re: cpu cores
On Sat, Jun 08, 2024 at 03:58:30PM +0200, Andreas Kähäri wrote: > On Sat, Jun 08, 2024 at 11:39:28AM +0100, Kirill A. Korinsky wrote: > > On Sat, 08 Jun 2024 11:09:29 +0100, > > Omar Polo wrote: > > > > > > On 2024/06/08 10:09:07 +0100, Kirill A. Korinsky wrote: > > > > On Sat, 08 Jun 2024 04:57:49 +0100, > > > > Gustavo Rios wrote: > > > > > > > > > > i have installed obsd on my dell notebook 8 cores processor. When i > > > > > execute > > > > > the top utility, it is showed the cores, from 0 (cpu0) to 7 (cpu7), > > > > > but > > > > > cpu1 and cpu3 is not listed. What is the problem ? > > > > > > > > > > > > > A blind guess: sysctl hw.smt=1 may return your hypertreading cores. > > > > > > which is a very bad advice to give. There's a reason sysctl hw.smt=1 > > > defaults to that value. One should rather give a "blind guess" of "your > > > hyperthread cores are disabled by default" rather than give a bad advice > > > without explanation. > > > > I'll make my advice cleaner, I defently mean that missed cores probably is > > disabled becuae it is hyperthreading ones which can be seen as offline in > > htop, or enable via sysctl. > > > Not knowing too much about these things, I think it looks a bit strange > that *two* out of eight CPUs are disabled due to hypethreading. I would > have expected every second one be disabled, i.e., four out of eight. This simple rule does not apply to more modern CPUs, which can have different types of cores, some with hyperthreading and some without. -Otto > > > > > > > Also, I'd like to add that from security point of view SMT in general and > > hyperthreading as an example is very bad idea. > > > > Thus, here old but interesting results that enabling hyperthreading has > > negative effect on performance of have CPU used applications: > > https://web.archive.org/web/20220325090914/http://users.telenet.be/nicvroom/performanceP4.htm > > > > -- > > wbr, Kirill > > -- > Andreas (Kusalananda) Kähäri > SciLifeLab, NBIS, ICM > Uppsala University, Sweden > > . >
Re: cpu cores
On Sat, Jun 08, 2024 at 11:39:28AM +0100, Kirill A. Korinsky wrote: > On Sat, 08 Jun 2024 11:09:29 +0100, > Omar Polo wrote: > > > > On 2024/06/08 10:09:07 +0100, Kirill A. Korinsky wrote: > > > On Sat, 08 Jun 2024 04:57:49 +0100, > > > Gustavo Rios wrote: > > > > > > > > i have installed obsd on my dell notebook 8 cores processor. When i > > > > execute > > > > the top utility, it is showed the cores, from 0 (cpu0) to 7 (cpu7), but > > > > cpu1 and cpu3 is not listed. What is the problem ? > > > > > > > > > > A blind guess: sysctl hw.smt=1 may return your hypertreading cores. > > > > which is a very bad advice to give. There's a reason sysctl hw.smt=1 > > defaults to that value. One should rather give a "blind guess" of "your > > hyperthread cores are disabled by default" rather than give a bad advice > > without explanation. > > I'll make my advice cleaner, I defently mean that missed cores probably is > disabled becuae it is hyperthreading ones which can be seen as offline in > htop, or enable via sysctl. Not knowing too much about these things, I think it looks a bit strange that *two* out of eight CPUs are disabled due to hypethreading. I would have expected every second one be disabled, i.e., four out of eight. > > Also, I'd like to add that from security point of view SMT in general and > hyperthreading as an example is very bad idea. > > Thus, here old but interesting results that enabling hyperthreading has > negative effect on performance of have CPU used applications: > https://web.archive.org/web/20220325090914/http://users.telenet.be/nicvroom/performanceP4.htm > > -- > wbr, Kirill -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: cpu cores
On Sat, 08 Jun 2024 11:09:29 +0100, Omar Polo wrote: > > On 2024/06/08 10:09:07 +0100, Kirill A. Korinsky wrote: > > On Sat, 08 Jun 2024 04:57:49 +0100, > > Gustavo Rios wrote: > > > > > > i have installed obsd on my dell notebook 8 cores processor. When i > > > execute > > > the top utility, it is showed the cores, from 0 (cpu0) to 7 (cpu7), but > > > cpu1 and cpu3 is not listed. What is the problem ? > > > > > > > A blind guess: sysctl hw.smt=1 may return your hypertreading cores. > > which is a very bad advice to give. There's a reason sysctl hw.smt=1 > defaults to that value. One should rather give a "blind guess" of "your > hyperthread cores are disabled by default" rather than give a bad advice > without explanation. I'll make my advice cleaner, I defently mean that missed cores probably is disabled becuae it is hyperthreading ones which can be seen as offline in htop, or enable via sysctl. Also, I'd like to add that from security point of view SMT in general and hyperthreading as an example is very bad idea. Thus, here old but interesting results that enabling hyperthreading has negative effect on performance of have CPU used applications: https://web.archive.org/web/20220325090914/http://users.telenet.be/nicvroom/performanceP4.htm -- wbr, Kirill
Re: cpu cores
On 2024/06/08 10:09:07 +0100, Kirill A. Korinsky wrote: > On Sat, 08 Jun 2024 04:57:49 +0100, > Gustavo Rios wrote: > > > > i have installed obsd on my dell notebook 8 cores processor. When i execute > > the top utility, it is showed the cores, from 0 (cpu0) to 7 (cpu7), but > > cpu1 and cpu3 is not listed. What is the problem ? > > > > A blind guess: sysctl hw.smt=1 may return your hypertreading cores. which is a very bad advice to give. There's a reason sysctl hw.smt=1 defaults to that value. One should rather give a "blind guess" of "your hyperthread cores are disabled by default" rather than give a bad advice without explanation.
Re: cpu cores
On Sat, 08 Jun 2024 04:57:49 +0100, Gustavo Rios wrote: > > i have installed obsd on my dell notebook 8 cores processor. When i execute > the top utility, it is showed the cores, from 0 (cpu0) to 7 (cpu7), but > cpu1 and cpu3 is not listed. What is the problem ? > A blind guess: sysctl hw.smt=1 may return your hypertreading cores. -- wbr, Kirill
Re: cpu cores
On Fri, Jun 7, 2024 at 10:58 PM Gustavo Rios wrote: > i have installed obsd on my dell notebook 8 cores processor. When i execute > the top utility, it is showed the cores, from 0 (cpu0) to 7 (cpu7), but cpu1 > and cpu3 is not listed. What is the problem ? You've been on these lists for over 15 years and yet didn't include a complete dmesg. Ok. If your dmesg completely lacks lines for cpu1 and cpu3 (but not 2 or 4 or 5) then it's a limitation of that exact model and how the BIOS has it configured. But that's really bizarre. Too bad we have zero information about your laptop and the cpus inside it. Philip Guenther
cpu cores
Hi folks! i have installed obsd on my dell notebook 8 cores processor. When i execute the top utility, it is showed the cores, from 0 (cpu0) to 7 (cpu7), but cpu1 and cpu3 is not listed. What is the problem ? Thanks a lot. -- The lion and the tiger may be more powerful, but the wolves do not perform in the circus
Re: Determining the number of CPU cores and hyperthreads from userspace
is this useful?:
$ cat sysconf.c
#include
#include
int
main()
{
printf("nproc configured %ld\n", sysconf(_SC_NPROCESSORS_CONF));
printf("nproc online %ld\n", sysconf(_SC_NPROCESSORS_ONLN));
return 0;
}
$ cc -o sysconf sysconf.c
$ ./sysconf
nproc configured 4
nproc online 2
On Sun, Sep 19, 2021 at 1:18 PM Chris Bennett <
cpb_m...@bennettconstruction.us> wrote:
> On Sun, Sep 19, 2021 at 01:37:05PM -0400, Daniel Wilkins wrote:
> > Hyperthreads are easy: they've been disabled for years (unless they got
> flipped on and I didn't notice.)
> >
>
> Does the setting in the BIOS need to be turned off also?
> Or is it irrelevant? I had a server for a while where the company
> insisted that it be left on in the BIOS.
>
> Thanks,
> Chris
>
>
Re: Determining the number of CPU cores and hyperthreads from userspace
On Sun, Sep 19, 2021 at 01:37:05PM -0400, Daniel Wilkins wrote: > Hyperthreads are easy: they've been disabled for years (unless they got > flipped on and I didn't notice.) > Does the setting in the BIOS need to be turned off also? Or is it irrelevant? I had a server for a while where the company insisted that it be left on in the BIOS. Thanks, Chris
Re: Determining the number of CPU cores and hyperthreads from userspace
Hyperthreads are easy: they've been disabled for years (unless they got flipped on and I didn't notice.)
Determining the number of CPU cores and hyperthreads from userspace
Hello, In the interest of fetching this information from Ansible for the GCC compile farm [1], I would like to determine the number of cores vs. hyper-threads on a system. With OpenBSD 6.9, this is what I get with "sysctl hw" on a dual 6-core Xeon system: hw.model=Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz hw.ncpu=24 hw.ncpufound=24 hw.smt=0 hw.ncpuonline=12 Because SMT is disabled, I can guess that there are 12 cores (ncpuonline) and 24 threads (ncpu), which is good. However, if SMT is enabled, this "guess" no longer works: hw.ncpu=24 hw.ncpufound=24 hw.smt=1 hw.ncpuonline=24 Is there another method that always works? I could parse the output of dmesg, it would work on this system: # dmesg | grep smt cpu0: smt 0, core 0, package 0 ... cpu12: smt 1, core 0, package 0 ... However, parsing dmesg was removed from Ansible in 2016 because it was not considered reliable enough: https://github.com/ansible/ansible/commit/c17dad0def2fa86733c07610189e94486e056203 In addition, this method would only work on amd64/i386 (according to the comment added in this commit). Thanks, Baptiste [1] https://cfarm.tetaneutral.net signature.asc Description: PGP signature
PF, CPU cores and usage of CPU turbo
Hi you OpenBSD pro:s… I have question regarding PF and thread use in kernel. If I got it right PF is single thread. Today the firewall I use uses a Jetway JNF9HG-2930 longlife 4 core N2930 @ 1.83GHz Celeron mainboard. It runs an OpenBSD 6.2 stable SMP kernel as I have not seen a penalty to use it over the uni kernel. The only kernel tuning I have done is to set net.inet.ip.ifq.maxlen=4096 to avoid the drops that I could see (on IPv6 as well...). I have 1/1 Gbit connection and fill almost the the whole pipe (approx 970 Mbit at 0.9 ms ) during speed tests. I am *very* *very* satisfied with OpenBSD :) here 970-980 Mbit speed tests load the kernel to approx 30% in my case. Yes, we route packet and not mega bytes :) I know... Now… I will soon have 10/10 GBit (not that I really need it though). For that I will switch over to a Xeon D-1521 with a Supermicro 2 x Intel 10 Gbit x540 PCI-e x8 card. This D-1521 is 2.2 GHz with turbo to 2.7 GHz and has just 2 cores. Now to the question… I have read the turbo is used automatically in CPUs under the right circumstances and the frequency increases against the turbo speed if very few cores are uses. I could very well test all cases to come to a conclusion. But still, I want to ask about your performance thoughts here. What is your opinion here if we talk about pure firewalling. Uni or smp? The question is with the thoughts in mind to be able to use the extra turbo frequence… The question is maybe stupid. But then, well, it is because I ask before dig deep into docs :) Tnx /Peo
Re: QEMU CPU cores not showing up
Em 15-11-2013 06:20, InterNetX - Robert Garrett escreveu: > Then as Stated you are already vulnerable to much more than interrupt > remapping will fix. So dont worry about it. Well, I said I have it enabled on my BIOS. Me having a sriov enabled kernel and a sriov capable NIC is another history. I'm justing making simple pci passthrough. Anyway, I'm not worrying much because it's OpenBSD. But it's kind of a bummer not being able to have more cores on it. Perhaps when I finish migrating the servers I can look into it. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: QEMU CPU cores not showing up
On Thu, 14 Nov 2013 09:51:04 -0700 Theo de Raadt wrote: > Then we'll be not be hearing from you again, I assume. > > > I am not putting up with this bulling shit. :) > > > > -- > > Bruno Delbono > > | Cognitive Researcher Doubtless. Dhu > > - Human Behavioural Project > > | Real Sociedad Espa__ola De Antropolog__a > > | ___: +1 855 253 5436 ___: +1 424 354 4700 > -- Ne obliviscaris, vix ea nostra voco.
Re: QEMU CPU cores not showing up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Then as Stated you are already vulnerable to much more than interrupt remapping will fix. So dont worry about it. On 11/14/2013 06:00 PM, Giancarlo Razzolini wrote: > Em 14-11-2013 14:18, InterNetX - Robert Garrett escreveu: >> The issue you outlined below is not an openbsd issue, this is a >> kvm issue. and depends greatly on the version of linux/whatever >> you are using. The interrupt remapping you are talking about is >> either a bios issue (likely) or an issue with the hypervisor. >> >> it sounds like to me you are using or attempting to use SRIOV. >> >> all of the issues that you mentioned are still relevent even >> with "safe interrupts", as well as several you did not mention. > Robert, > > I do believe it is a specific issue with OpenBSD, because using > the same hypervisor I can do pci passthrough, using the same > versions, hardware, etc, to other operating systems using interrupt > remapping. > > I do have indeed SRIOV enabled on my bare metal bios. The thing is > that kvm specifically warns me that the guest do not support > interrupt remapping, when using openbsd only. As I told before, it > is not a problem for me right now, since I enable the unsafe > interrupt assignment and the OS works normally. > > Also, David, thanks for pointing out the patch, because since I > applied it, I did not experienced anymore lockups (so far). I am > betting it was indeed the problem. Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJShdk4AAoJEMrvovfl62c8DVEIALQmLbVLlnEsayXgpvCNiO2g gWF0+L4haMA7Rhf7FvRqOpXxCcZVhxk5ocEvSHLnyG1iYfh3tlnq1ts8rk9dfSHT DP1QA0ReXvVJKW2r8UcLVfI62H6gA93TiFZWLzFioO6NZExKlfe3DCWDg3scBqg3 dZFE7fcQW5iUjOdKJzw79DBTN1FlQUxeZ5EAGXN19XZAezbHP08KmmyAkil7jvqf DRFVRT7xnh0Vqa5H6Iz4KrQcasIPiLnt6ggxRzCxXL2EKu8K5Htwc9/LD4Jynz6y YVPKEPrL0lJ03ocb+U47vSynTfFWjDbOdKeIikqhUFDccfwTWUtefSVGmTzzdgQ= =tyuk -END PGP SIGNATURE-
Re: QEMU CPU cores not showing up
| -Original Message- | From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On | Behalf Of Bruno Delbono | Sent: Thursday, November 14, 2013 10:48 AM | To: Theo de Raadt | Cc: misc@openbsd.org; mlar...@azathoth.net | Subject: Re: QEMU CPU cores not showing up | Useless crying removed... | PS - Telling me to stick a screw driver in my ear? Ya seriously eff off...I am not | putting up with this bulling shit. :) Good, I for one am glad you are leaving and taking your self-entitled attitude with you. If you want something fixed that no developer cares about, then shut up and code it yourself. Prick, indeed. -Breeno
Re: QEMU CPU cores not showing up
Em 14-11-2013 14:18, InterNetX - Robert Garrett escreveu: > The issue you outlined below is not an openbsd issue, this is a kvm > issue. and depends greatly on the version of linux/whatever you are > using. The interrupt remapping you are talking about is either a bios > issue (likely) or an issue with the hypervisor. > > it sounds like to me you are using or attempting to use SRIOV. > > all of the issues that you mentioned are still relevent even with > "safe interrupts", as well as several you did not mention. Robert, I do believe it is a specific issue with OpenBSD, because using the same hypervisor I can do pci passthrough, using the same versions, hardware, etc, to other operating systems using interrupt remapping. I do have indeed SRIOV enabled on my bare metal bios. The thing is that kvm specifically warns me that the guest do not support interrupt remapping, when using openbsd only. As I told before, it is not a problem for me right now, since I enable the unsafe interrupt assignment and the OS works normally. Also, David, thanks for pointing out the patch, because since I applied it, I did not experienced anymore lockups (so far). I am betting it was indeed the problem. -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: QEMU CPU cores not showing up
Then we'll be not be hearing from you again, I assume. > I am not putting up with this bulling shit. :) > > -- > Bruno Delbono > | Cognitive Researcher - Human Behavioural Project > | Real Sociedad Española De AntropologÃa > | â: +1 855 253 5436 â: +1 424 354 4700
Re: QEMU CPU cores not showing up
Theo, I wonder when will you stop being a condescending prick? I understand you and many of the actually nicer devs here on OpenBSD, have contributed towards computer security. And yet you have been in public and private, called a bully numerous times now. I have a faint recollection of meeting you at CanSec West in Vancouver a decade ago and oddly this arrogance remains. At that time I was younger and OpenBSD was the shit! Sigh...youth Remember when you change IPv6 in OpenBSD also about a decade ago? I had to work with Philip Hazel on Exim to work properly with the new way of thinking that was your way. Or the time when x2 remote root exploit was floating on the internet (even before it went wild)? With IPv6, a decade later neither has the adoption increased as predicted nor has those security problem you claimed affected the other OS's to show your way was better. And I remember your reluctance to deal with x2...or the time you just pulled ipfilter until pf saved your ass.. I mean is your head that up your ass that you think being an incredibly idiotic bully with an OS that barely functions properly to begin with, helps? Quite frankly, I am just annoyed now that I am spending time trying to figure out why this one-man OS is so dumb that all other OS's in the world see four cores except - oh wait, OpenBSD. I am sure the hundreds and hundreds...no, sorry just the hundred of OpenBSD users will benefit. PS - Telling me to stick a screw driver in my ear? Ya seriously eff off...I am not putting up with this bulling shit. :) -- Bruno Delbono | Cognitive Researcher - Human Behavioural Project | Real Sociedad Española De Antropología | ☎: +1 855 253 5436 ☎: +1 424 354 4700 From: Theo de Raadt Sent: Wednesday, November 13, 2013 5:29 PM To: Bruno Delbono Cc: misc@openbsd.org; mlar...@azathoth.net Subject: Re: QEMU CPU cores not showing up > Sigh, Theo. Seriously I am asking for your help to find out the > issue as its unique to OpenBSD. > Stop ranting away on the demerits of disabling apm (and now pci - right! > wtf?!). Then stop justifying your blind following of what you read on the web. It looks too much like incompetence. > Like dude, have you never tried variations of anything except > default bsd kernel? Why is tinkering (and not even permanent - just > dmesg outputs) considered such an anathema? Hey, stick a screw driver into your ear. Does it help anything? No. And that is why it is discouraged. Don't use boot -c thinking it will fix things for you. It won't. That is not what it is for. boot -c is not a magic tool that solves bugs. From time to time I wonder if we should delete it. It looks like it is only used by people who read web pages.
Re: QEMU CPU cores not showing up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The issue you outlined below is not an openbsd issue, this is a kvm issue. and depends greatly on the version of linux/whatever you are using. The interrupt remapping you are talking about is either a bios issue (likely) or an issue with the hypervisor. it sounds like to me you are using or attempting to use SRIOV. all of the issues that you mentioned are still relevent even with "safe interrupts", as well as several you did not mention. RG On 11/14/2013 03:15 PM, Giancarlo Razzolini wrote: > Em 14-11-2013 11:43, David Coppa escreveu: >> On Thu, Nov 14, 2013 at 2:33 PM, Giancarlo Razzolini >> wrote: >>> Em 13-11-2013 22:40, Jeff Fuhrman escreveu: I'm the tech Bruno has been working with regarding this. QEMU version is 1.5 and the relevant section of the KVM Config file is " 4>>> threads='1'/>". We've tried it with 2 sockets, with 4 sockets, with 2 threads, 4 threads, and so on. ACPI and APIC are enabled for the KVM Container. Jeff Fuhrman Level 2 Technician - BlueVM >>> I have the same issue using the same qemu version. Do you guys >>> also experience random lockups? I've seem sometimes the OpenBSD >>> VM sshd will simply stop answering. Also if I try to login >>> directly through the VM's console, when I insert the username >>> it will not prompt me for a password. The strangest thing is, >>> the machine still answer ping packets. I could not debug it >>> yet, since it happens randomly. I have to force a shutdown to >>> be able to access the machine again. >> Have you applied the patch for the errata below? >> >> for 5.4: >> >> http://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/003_vnode.patch >> >> >> or for 5.3: >> >> http://ftp.openbsd.org/pub/OpenBSD/patches/5.3/common/010_vnode.patch > >> Not yet David, will look into it. I am moving almost all of my > infrastructure servers to virtualized ones. Even my firewall is > virtualized now. But I am experienced these random lockups now and > then. Will apply the patch and test it again. > > I do have another issue with running an OpenBSD guest in which it > wont do interrupt remapping so I have to enable an unsafe behavior > on kvm which allows it to do pci passthrough with "unsafe" > interrupts. There are some issues using this in which a privileged > user in the guest machine could escalate it's privileges on the > host and/or crash it. Anyway, this isn't a problem for me right > now, when I do have some time I'll look into it. > > Thanks, Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJShPfBAAoJEMrvovfl62c88fcIAIhs4nW2+Tv/TMlg/+ePvPpD o5twuabaHfim9iYMqyAHQEztR8Nm4eFWilrFE3AZP2zvoPHLvxWuApZe1rr03FIy CUnPlzhde+e38ggC0r5OQkV3tURpEWr3Uk7Yjzr2hxg47/syX15XYSEERtaSAaOY 3vv8Kt3IFXVZFHg+EM9dQCMMrNuXwxp2eg7Gej7S2Gv6mO7yWyniM7uhLTrqGwtP AFx36o6XSMzxqq4ooN8/seMMlnP075o45b8rhKHRRX4BgZ7eRI5z+ZglVJF9wSo7 GNPQZGWqwpfACDREOY/U0rmk4iG+RwBplKhprCZgnsvoQAJfdbFcOPVnzUDbpYQ= =lvPc -END PGP SIGNATURE-
Re: QEMU CPU cores not showing up
Em 14-11-2013 11:43, David Coppa escreveu: > On Thu, Nov 14, 2013 at 2:33 PM, Giancarlo Razzolini > wrote: >> Em 13-11-2013 22:40, Jeff Fuhrman escreveu: >>> I'm the tech Bruno has been working with regarding this. QEMU version is >>> 1.5 and the relevant section of the KVM Config file is " >>> 4". >>> We've tried it with 2 sockets, with 4 sockets, with 2 threads, 4 threads, >>> and so on. ACPI and APIC are enabled for the KVM Container. >>> >>> Jeff Fuhrman >>> Level 2 Technician - BlueVM >> I have the same issue using the same qemu version. Do you guys also >> experience random lockups? I've seem sometimes the OpenBSD VM sshd will >> simply stop answering. Also if I try to login directly through the VM's >> console, when I insert the username it will not prompt me for a >> password. The strangest thing is, the machine still answer ping packets. >> I could not debug it yet, since it happens randomly. I have to force a >> shutdown to be able to access the machine again. > Have you applied the patch for the errata below? > > for 5.4: > > http://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/003_vnode.patch > > or for 5.3: > > http://ftp.openbsd.org/pub/OpenBSD/patches/5.3/common/010_vnode.patch Not yet David, will look into it. I am moving almost all of my infrastructure servers to virtualized ones. Even my firewall is virtualized now. But I am experienced these random lockups now and then. Will apply the patch and test it again. I do have another issue with running an OpenBSD guest in which it wont do interrupt remapping so I have to enable an unsafe behavior on kvm which allows it to do pci passthrough with "unsafe" interrupts. There are some issues using this in which a privileged user in the guest machine could escalate it's privileges on the host and/or crash it. Anyway, this isn't a problem for me right now, when I do have some time I'll look into it. Thanks, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: QEMU CPU cores not showing up
On Thu, Nov 14, 2013 at 2:33 PM, Giancarlo Razzolini wrote: > Em 13-11-2013 22:40, Jeff Fuhrman escreveu: >> I'm the tech Bruno has been working with regarding this. QEMU version is 1.5 >> and the relevant section of the KVM Config file is " >> 4". >> We've tried it with 2 sockets, with 4 sockets, with 2 threads, 4 threads, >> and so on. ACPI and APIC are enabled for the KVM Container. >> >> Jeff Fuhrman >> Level 2 Technician - BlueVM > I have the same issue using the same qemu version. Do you guys also > experience random lockups? I've seem sometimes the OpenBSD VM sshd will > simply stop answering. Also if I try to login directly through the VM's > console, when I insert the username it will not prompt me for a > password. The strangest thing is, the machine still answer ping packets. > I could not debug it yet, since it happens randomly. I have to force a > shutdown to be able to access the machine again. Have you applied the patch for the errata below? for 5.4: http://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/003_vnode.patch or for 5.3: http://ftp.openbsd.org/pub/OpenBSD/patches/5.3/common/010_vnode.patch
Re: QEMU CPU cores not showing up
Em 13-11-2013 22:40, Jeff Fuhrman escreveu: > I'm the tech Bruno has been working with regarding this. QEMU version is 1.5 > and the relevant section of the KVM Config file is " > 4". > We've tried it with 2 sockets, with 4 sockets, with 2 threads, 4 threads, and > so on. ACPI and APIC are enabled for the KVM Container. > > Jeff Fuhrman > Level 2 Technician - BlueVM I have the same issue using the same qemu version. Do you guys also experience random lockups? I've seem sometimes the OpenBSD VM sshd will simply stop answering. Also if I try to login directly through the VM's console, when I insert the username it will not prompt me for a password. The strangest thing is, the machine still answer ping packets. I could not debug it yet, since it happens randomly. I have to force a shutdown to be able to access the machine again. To add to the strange thing, I have another bare metal machine, with a different hardware, but using the same qemu version, and I had never experienced any lockups. But it also will not show more cores on OpenBSD. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: QEMU CPU cores not showing up
2013/11/13 Bruno Delbono > Stop ranting away on the demerits of disabling apm (and now pci - right! > wtf?!). > He's not. He's rambling about you twisting knobs without having any kind of clue as to why or how it would have helped, probably based on an outdated guide which now also don't know why or how it would help. -- May the most significant bit of your life be positive.
Re: QEMU CPU cores not showing up
I'm the tech Bruno has been working with regarding this. QEMU version is 1.5 and the relevant section of the KVM Config file is " 4". We've tried it with 2 sockets, with 4 sockets, with 2 threads, 4 threads, and so on. ACPI and APIC are enabled for the KVM Container. Jeff Fuhrman Level 2 Technician - BlueVM -Original Message- From: Bruno Delbono [mailto:b...@t.gt] Sent: Wednesday, November 13, 2013 2:25 PM To: Theo de Raadt; Theo de Raadt Cc: misc@openbsd.org; mlar...@azathoth.net; misc@openbsd.org; mlar...@azathoth.net Subject: Re: QEMU CPU cores not showing up Sigh, Theo. Seriously I am asking for your help to find out the issue as its unique to OpenBSD. Stop ranting away on the demerits of disabling apm (and now pci - right! wtf?!). Like dude, have you never tried variations of anything except default bsd kernel? Why is tinkering (and not even permanent - just dmesg outputs) considered such an anathema? The world didn't collapse by disabling apm and neither did it work. Did I mention I tried the GENERIC.MP too? I am sure I did...oh right, a line below... Look, I am looking for advice from devs like you on why this is happening? Please chill, I come in peace for christ sake! Telling me to ask them about AP (the only advice so far) is not a good question. -- Bruno Delbono | Cognitive Researcher - Human Behavioural Project Real Sociedad | Española De Antropología | ☎: +1 855 253 5436 ☎: +1 424 354 4700 From: Theo de Raadt Sent: Wednesday, November 13, 2013 5:13 PM To: Bruno Delbono Cc: misc@openbsd.org; mlar...@azathoth.net Subject: Re: QEMU CPU cores not showing up > As for why completely random disabling apm and acpi...rant by you and Theo... Bullshit. Perhaps the solution you are looking for is: boot -c > disable pci* You never know, it just might work. We are not ranting. We're telling you that you don't know what the hell you are doing, and you are following bad advice.
Re: QEMU CPU cores not showing up
Sigh, Theo. Seriously I am asking for your help to find out the issue as its unique to OpenBSD. Stop ranting away on the demerits of disabling apm (and now pci - right! wtf?!). Like dude, have you never tried variations of anything except default bsd kernel? Why is tinkering (and not even permanent - just dmesg outputs) considered such an anathema? The world didn't collapse by disabling apm and neither did it work. Did I mention I tried the GENERIC.MP too? I am sure I did...oh right, a line below... Look, I am looking for advice from devs like you on why this is happening? Please chill, I come in peace for christ sake! Telling me to ask them about AP (the only advice so far) is not a good question. -- Bruno Delbono | Cognitive Researcher - Human Behavioural Project | Real Sociedad Española De Antropología | ☎: +1 855 253 5436 ☎: +1 424 354 4700 From: Theo de Raadt Sent: Wednesday, November 13, 2013 5:13 PM To: Bruno Delbono Cc: misc@openbsd.org; mlar...@azathoth.net Subject: Re: QEMU CPU cores not showing up > As for why completely random disabling apm and acpi...rant by you and Theo... Bullshit. Perhaps the solution you are looking for is: boot -c > disable pci* You never know, it just might work. We are not ranting. We're telling you that you don't know what the hell you are doing, and you are following bad advice.
Re: QEMU CPU cores not showing up
Theo, fine. Truce. I just got advice from jirib@ to ask my provider about: Show qemu/kvm args! Ask provider what does he use, which qemu/KVM, which distro... Try to define 2 sockets, each one core, I bet it will work. . I will report back as soon as they do this. And include full dmesg output in my mail rather than outside providers. My apologies about that.. -- Bruno Delbono | Cognitive Researcher - Human Behavioural Project | Real Sociedad Española De Antropología | ☎: +1 855 253 5436 ☎: +1 424 354 4700 From: Theo de Raadt Sent: Wednesday, November 13, 2013 5:29 PM To: Bruno Delbono Cc: misc@openbsd.org; mlar...@azathoth.net Subject: Re: QEMU CPU cores not showing up > Sigh, Theo. Seriously I am asking for your help to find out the > issue as its unique to OpenBSD. > Stop ranting away on the demerits of disabling apm (and now pci - right! > wtf?!). Then stop justifying your blind following of what you read on the web. It looks too much like incompetence. > Like dude, have you never tried variations of anything except > default bsd kernel? Why is tinkering (and not even permanent - just > dmesg outputs) considered such an anathema? Hey, stick a screw driver into your ear. Does it help anything? No. And that is why it is discouraged. Don't use boot -c thinking it will fix things for you. It won't. That is not what it is for. boot -c is not a magic tool that solves bugs. From time to time I wonder if we should delete it. It looks like it is only used by people who read web pages.
Re: QEMU CPU cores not showing up
> Sigh, Theo. Seriously I am asking for your help to find out the > issue as its unique to OpenBSD. > Stop ranting away on the demerits of disabling apm (and now pci - right! > wtf?!). Then stop justifying your blind following of what you read on the web. It looks too much like incompetence. > Like dude, have you never tried variations of anything except > default bsd kernel? Why is tinkering (and not even permanent - just > dmesg outputs) considered such an anathema? Hey, stick a screw driver into your ear. Does it help anything? No. And that is why it is discouraged. Don't use boot -c thinking it will fix things for you. It won't. That is not what it is for. boot -c is not a magic tool that solves bugs. From time to time I wonder if we should delete it. It looks like it is only used by people who read web pages.
Re: QEMU CPU cores not showing up
> As for why completely random disabling apm and acpi...rant by you and Theo... Bullshit. Perhaps the solution you are looking for is: boot -c > disable pci* You never know, it just might work. We are not ranting. We're telling you that you don't know what the hell you are doing, and you are following bad advice.
Re: QEMU CPU cores not showing up
Mike, I've asked the provider to look into it. As for why completely random disabling apm and acpi...rant by you and Theo...please see that they are all output that have been tried including booting generic.mp. Its not that it was randomly disabled, it was tested to see if there is a difference. I gave dmesg from all variations I tried before asking misc@ "including" GENERIC.MP and snapshot MP. I don't get why you and Theo have to go on a rant when the Generic.MP dmesg output is a line below... Sigh. Anyway, I am asking my provider about this. Is there anything specific that OpenBSD may need that none of the other OS's, even Windows Vista that works with, needs? Like telling me ask about AP to them is not very helpful. I need to know what specifically is missing between the same QEMU instance between OpenBSD and any other OS that works fine... Bruno Delbono | Cognitive Researcher - Human Behavioural Project | Real Sociedad Española De Antropología | ☎: +1 855 253 5436 ☎: +1 424 354 4700 From: Mike Larkin Sent: Wednesday, November 13, 2013 4:13 PM To: Bruno Delbono; misc@openbsd.org Subject: Re: QEMU CPU cores not showing up On Wed, Nov 13, 2013 at 09:44:11PM +0100, Otto Moerbeek wrote: > On Wed, Nov 13, 2013 at 08:26:57PM +, Bruno Delbono wrote: > > > Hi Otto, > > > > http://pastebin.com/zfkEUxX8 > > > > This is generic.mp with flags of apm and acpi disable > > Why would you start trying to disable random devices in the kernel and expect things to get any better? For the past several years, acpi is needed on most machines to do anything useful with those machines. That includes VMs. > > http://pastebin.com/PEjCr2vY > > > > Generic.MP boot. > > > > I am not sure what is wrong and why this works with all the other OS's... >From your output, there are no APs being presented to the VM. Talk to your >cloud provider. -ml > > No clue then. Maybe some kernel hacker can guess. > > -Otto > > > > > > -- > > > > Bruno Delbono > > | Cognitive Researcher - Human Behavioural Project > > | Real Sociedad Espa??ola De Antropolog??a > > | ???: +1 855 253 5436 ???: +1 424 354 4700 > > > > ________ > > From: Otto Moerbeek > > Sent: Wednesday, November 13, 2013 3:11 PM > > To: Bruno Delbono > > Cc: misc@openbsd.org > > Subject: Re: QEMU CPU cores not showing up > > > > On Wed, Nov 13, 2013 at 07:36:58PM +, Bruno Delbono wrote: > > > > > Hello, > > > > > > > > > I have a QEMU instance that works perfectly fine at detecting cpu cores on > > > NetBSD/FreeBSD/Linux. All except OpenBSD 5.4 > > > > > > > > > - I have tried the GENERIC amd64 and i386 bsd.mp kernel and the bsd.mp > > > snapshot kernel. > > > > Use the GENERIC.MP kernel. > > > > > > > > - I have tried disabling apm and acpi* during boot config > > > > > > > > > I am completely lost as to why this may be happening. You can see the > > > NetBSD > > > boot 6.1.2 on the same machine here: > > > > > > > > > http://pastebin.com/FJeiRp9t > > > > > > > > > You can see OpenBSD snapshot boot (please ignore disable acpi vs acpiprt* > > > - I > > > tried both) here: > > > > > > > > > http://pastebin.com/v9XWv4XY > > > > > > > > > I am using BlueVM (www.BlueVM.com<http://www.BlueVM.com>) as my KVM > > > provider. > > > > > > > > > Can anyone guide me on what I should do or try next? Is it a QEMU issue > > > with > > > the Cloud Services Provider? > > > > > > > > > Thanks, > > > > > > > > > -Bruno
Re: QEMU CPU cores not showing up
On Wed, Nov 13, 2013 at 10:29:34PM +0100, Peter J. Philipp wrote: > He took the advice from me on IRC. I had googled and found a similar > mail from someone who could not see 2 cpu's but only 1, people told that > person to disable apm, but granted the mails were a little dated. > > So I was giving the bad advice. I'll keep the acpi thing in mind for > next time. > > Cheers, > > -peter The issue is how you define cpus as arguments for KVM/qemu. I have seen same issue with RHEVM (KVM/libvirt with fancy UI). The reporter should stop using 3rd party web sites for output, he loses our time, and put as much as info inside the mail. Show qemu/kvm args! Ask provider what does he use, which qemu/KVM, which distro... Try to define 2 sockets, each one core, I bet it will work. jirib
Re: QEMU CPU cores not showing up
On 11/13/13 22:13, Mike Larkin wrote: > On Wed, Nov 13, 2013 at 09:44:11PM +0100, Otto Moerbeek wrote: >> On Wed, Nov 13, 2013 at 08:26:57PM +, Bruno Delbono wrote: >> >>> Hi Otto, >>> >>> http://pastebin.com/zfkEUxX8 >>> >>> This is generic.mp with flags of apm and acpi disable >>> > > Why would you start trying to disable random devices in the kernel and expect > things to get any better? For the past several years, acpi is needed on most > machines to do anything useful with those machines. That includes VMs. > He took the advice from me on IRC. I had googled and found a similar mail from someone who could not see 2 cpu's but only 1, people told that person to disable apm, but granted the mails were a little dated. So I was giving the bad advice. I'll keep the acpi thing in mind for next time. Cheers, -peter >>> http://pastebin.com/PEjCr2vY >>> >>> Generic.MP boot. >>> >>> I am not sure what is wrong and why this works with all the other OS's... > >>From your output, there are no APs being presented to the VM. Talk to your >>cloud > provider. > > -ml > >> >> No clue then. Maybe some kernel hacker can guess. >> >> -Otto >>> >>> >>> -- >>> >>> Bruno Delbono >>> | Cognitive Researcher - Human Behavioural Project >>> | Real Sociedad Espa??ola De Antropolog??a >>> | ???: +1 855 253 5436 ???: +1 424 354 4700 >>> >>> >>> From: Otto Moerbeek >>> Sent: Wednesday, November 13, 2013 3:11 PM >>> To: Bruno Delbono >>> Cc: misc@openbsd.org >>> Subject: Re: QEMU CPU cores not showing up >>> >>> On Wed, Nov 13, 2013 at 07:36:58PM +, Bruno Delbono wrote: >>> >>>> Hello, >>>> >>>> >>>> I have a QEMU instance that works perfectly fine at detecting cpu cores on >>>> NetBSD/FreeBSD/Linux. All except OpenBSD 5.4 >>>> >>>> >>>> - I have tried the GENERIC amd64 and i386 bsd.mp kernel and the bsd.mp >>>> snapshot kernel. >>> >>> Use the GENERIC.MP kernel. >>> >>>> >>>> - I have tried disabling apm and acpi* during boot config >>>> >>>> >>>> I am completely lost as to why this may be happening. You can see the >>>> NetBSD >>>> boot 6.1.2 on the same machine here: >>>> >>>> >>>> http://pastebin.com/FJeiRp9t >>>> >>>> >>>> You can see OpenBSD snapshot boot (please ignore disable acpi vs acpiprt* >>>> - I >>>> tried both) here: >>>> >>>> >>>> http://pastebin.com/v9XWv4XY >>>> >>>> >>>> I am using BlueVM (www.BlueVM.com<http://www.BlueVM.com>) as my KVM >>>> provider. >>>> >>>> >>>> Can anyone guide me on what I should do or try next? Is it a QEMU issue >>>> with >>>> the Cloud Services Provider? >>>> >>>> >>>> Thanks, >>>> >>>> >>>> -Bruno
Re: QEMU CPU cores not showing up
> On Wed, Nov 13, 2013 at 09:44:11PM +0100, Otto Moerbeek wrote: > > On Wed, Nov 13, 2013 at 08:26:57PM +, Bruno Delbono wrote: > > > > > Hi Otto, > > > > > > http://pastebin.com/zfkEUxX8 > > > > > > This is generic.mp with flags of apm and acpi disable > > > > > Why would you start trying to disable random devices in the kernel and expect > things to get any better? For the past several years, acpi is needed on most > machines to do anything useful with those machines. That includes VMs. Completely right. As a general policy, if anyone sends a message which indicates that they have disabled ACPI, I recommend that everyone ignore them. ACPI is REQUIRED. Any advice about disabling it is COMPLETELY AND UTTERLY FALSE AND MISLEADING. You will NOT get anywhere by disabling it. You might as well turn off cpu0 while at it.
Re: QEMU CPU cores not showing up
On Wed, Nov 13, 2013 at 09:44:11PM +0100, Otto Moerbeek wrote: > On Wed, Nov 13, 2013 at 08:26:57PM +, Bruno Delbono wrote: > > > Hi Otto, > > > > http://pastebin.com/zfkEUxX8 > > > > This is generic.mp with flags of apm and acpi disable > > Why would you start trying to disable random devices in the kernel and expect things to get any better? For the past several years, acpi is needed on most machines to do anything useful with those machines. That includes VMs. > > http://pastebin.com/PEjCr2vY > > > > Generic.MP boot. > > > > I am not sure what is wrong and why this works with all the other OS's... >From your output, there are no APs being presented to the VM. Talk to your >cloud provider. -ml > > No clue then. Maybe some kernel hacker can guess. > > -Otto > > > > > > -- > > > > Bruno Delbono > > | Cognitive Researcher - Human Behavioural Project > > | Real Sociedad Espa??ola De Antropolog??a > > | ???: +1 855 253 5436 ???: +1 424 354 4700 > > > > ________ > > From: Otto Moerbeek > > Sent: Wednesday, November 13, 2013 3:11 PM > > To: Bruno Delbono > > Cc: misc@openbsd.org > > Subject: Re: QEMU CPU cores not showing up > > > > On Wed, Nov 13, 2013 at 07:36:58PM +, Bruno Delbono wrote: > > > > > Hello, > > > > > > > > > I have a QEMU instance that works perfectly fine at detecting cpu cores on > > > NetBSD/FreeBSD/Linux. All except OpenBSD 5.4 > > > > > > > > > - I have tried the GENERIC amd64 and i386 bsd.mp kernel and the bsd.mp > > > snapshot kernel. > > > > Use the GENERIC.MP kernel. > > > > > > > > - I have tried disabling apm and acpi* during boot config > > > > > > > > > I am completely lost as to why this may be happening. You can see the > > > NetBSD > > > boot 6.1.2 on the same machine here: > > > > > > > > > http://pastebin.com/FJeiRp9t > > > > > > > > > You can see OpenBSD snapshot boot (please ignore disable acpi vs acpiprt* > > > - I > > > tried both) here: > > > > > > > > > http://pastebin.com/v9XWv4XY > > > > > > > > > I am using BlueVM (www.BlueVM.com<http://www.BlueVM.com>) as my KVM > > > provider. > > > > > > > > > Can anyone guide me on what I should do or try next? Is it a QEMU issue > > > with > > > the Cloud Services Provider? > > > > > > > > > Thanks, > > > > > > > > > -Bruno
Re: QEMU CPU cores not showing up
On Wed, Nov 13, 2013 at 08:26:57PM +, Bruno Delbono wrote: > Hi Otto, > > http://pastebin.com/zfkEUxX8 > > This is generic.mp with flags of apm and acpi disable > > http://pastebin.com/PEjCr2vY > > Generic.MP boot. > > I am not sure what is wrong and why this works with all the other OS's... No clue then. Maybe some kernel hacker can guess. -Otto > > > -- > > Bruno Delbono > | Cognitive Researcher - Human Behavioural Project > | Real Sociedad Espa??ola De Antropolog??a > | ???: +1 855 253 5436 ???: +1 424 354 4700 > > > From: Otto Moerbeek > Sent: Wednesday, November 13, 2013 3:11 PM > To: Bruno Delbono > Cc: misc@openbsd.org > Subject: Re: QEMU CPU cores not showing up > > On Wed, Nov 13, 2013 at 07:36:58PM +, Bruno Delbono wrote: > > > Hello, > > > > > > I have a QEMU instance that works perfectly fine at detecting cpu cores on > > NetBSD/FreeBSD/Linux. All except OpenBSD 5.4 > > > > > > - I have tried the GENERIC amd64 and i386 bsd.mp kernel and the bsd.mp > > snapshot kernel. > > Use the GENERIC.MP kernel. > > > > > - I have tried disabling apm and acpi* during boot config > > > > > > I am completely lost as to why this may be happening. You can see the NetBSD > > boot 6.1.2 on the same machine here: > > > > > > http://pastebin.com/FJeiRp9t > > > > > > You can see OpenBSD snapshot boot (please ignore disable acpi vs acpiprt* - > > I > > tried both) here: > > > > > > http://pastebin.com/v9XWv4XY > > > > > > I am using BlueVM (www.BlueVM.com<http://www.BlueVM.com>) as my KVM > > provider. > > > > > > Can anyone guide me on what I should do or try next? Is it a QEMU issue with > > the Cloud Services Provider? > > > > > > Thanks, > > > > > > -Bruno
Re: QEMU CPU cores not showing up
Hi Otto, http://pastebin.com/zfkEUxX8 This is generic.mp with flags of apm and acpi disable http://pastebin.com/PEjCr2vY Generic.MP boot. I am not sure what is wrong and why this works with all the other OS's... -- Bruno Delbono | Cognitive Researcher - Human Behavioural Project | Real Sociedad Española De Antropología | ☎: +1 855 253 5436 ☎: +1 424 354 4700 From: Otto Moerbeek Sent: Wednesday, November 13, 2013 3:11 PM To: Bruno Delbono Cc: misc@openbsd.org Subject: Re: QEMU CPU cores not showing up On Wed, Nov 13, 2013 at 07:36:58PM +, Bruno Delbono wrote: > Hello, > > > I have a QEMU instance that works perfectly fine at detecting cpu cores on > NetBSD/FreeBSD/Linux. All except OpenBSD 5.4 > > > - I have tried the GENERIC amd64 and i386 bsd.mp kernel and the bsd.mp > snapshot kernel. Use the GENERIC.MP kernel. > > - I have tried disabling apm and acpi* during boot config > > > I am completely lost as to why this may be happening. You can see the NetBSD > boot 6.1.2 on the same machine here: > > > http://pastebin.com/FJeiRp9t > > > You can see OpenBSD snapshot boot (please ignore disable acpi vs acpiprt* - I > tried both) here: > > > http://pastebin.com/v9XWv4XY > > > I am using BlueVM (www.BlueVM.com<http://www.BlueVM.com>) as my KVM provider. > > > Can anyone guide me on what I should do or try next? Is it a QEMU issue with > the Cloud Services Provider? > > > Thanks, > > > -Bruno
Re: QEMU CPU cores not showing up
On Wed, Nov 13, 2013 at 07:36:58PM +, Bruno Delbono wrote: > Hello, > > > I have a QEMU instance that works perfectly fine at detecting cpu cores on > NetBSD/FreeBSD/Linux. All except OpenBSD 5.4 > > > - I have tried the GENERIC amd64 and i386 bsd.mp kernel and the bsd.mp > snapshot kernel. Use the GENERIC.MP kernel. > > - I have tried disabling apm and acpi* during boot config > > > I am completely lost as to why this may be happening. You can see the NetBSD > boot 6.1.2 on the same machine here: > > > http://pastebin.com/FJeiRp9t > > > You can see OpenBSD snapshot boot (please ignore disable acpi vs acpiprt* - I > tried both) here: > > > http://pastebin.com/v9XWv4XY > > > I am using BlueVM (www.BlueVM.com<http://www.BlueVM.com>) as my KVM provider. > > > Can anyone guide me on what I should do or try next? Is it a QEMU issue with > the Cloud Services Provider? > > > Thanks, > > > -Bruno
QEMU CPU cores not showing up
Hello, I have a QEMU instance that works perfectly fine at detecting cpu cores on NetBSD/FreeBSD/Linux. All except OpenBSD 5.4 - I have tried the GENERIC amd64 and i386 bsd.mp kernel and the bsd.mp snapshot kernel. - I have tried disabling apm and acpi* during boot config I am completely lost as to why this may be happening. You can see the NetBSD boot 6.1.2 on the same machine here: http://pastebin.com/FJeiRp9t You can see OpenBSD snapshot boot (please ignore disable acpi vs acpiprt* - I tried both) here: http://pastebin.com/v9XWv4XY I am using BlueVM (www.BlueVM.com<http://www.BlueVM.com>) as my KVM provider. Can anyone guide me on what I should do or try next? Is it a QEMU issue with the Cloud Services Provider? Thanks, -Bruno
