Re: Snapshots in QEMU
My bad then, just that I saw this commit and I thought that this was a sort of workaround: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/identcpu.c?rev=1.104=text/x-cvsweb-markup Cheers. Elias. 2018-08-07 16:59 GMT-03:00 Theo de Raadt : > Elias M. Mariani wrote: > >> You are right, is KVM's bug. >> But this was fixed on -snapshots right? > > No. > >> If so, OpenBSD 6.4 would work well, bypassing KVM's bug. > > No. >
Re: Snapshots in QEMU
You are right, is KVM's bug. But this was fixed on -snapshots right? If so, OpenBSD 6.4 would work well, bypassing KVM's bug. Cheers. Elias. 2018-08-07 16:27 GMT-03:00 Theo de Raadt : > We don't agree. > > We consider it a bug in KVM. > > Doesn't KVM suggest they are emulating a real machine? AMD has > documented that MSR. So KVM should emulate the MSR. In some > way, even perhaps act like it is a NOP. > > Or they shouldn't claim to be that CPU. > > Feel free to report to those other upstreams. > > Elias M. Mariani wrote: >> Sorry to keep pinging this one. >> If you install OPENBSD_6_3 in KVM/QEMU and run syspatch and apply the >> LFENCE patch the machine redeems unable to boot. >> I think that this should be another patch to fix the problem, anyone >> using a OpenBSD virtual server with that config will ruin the boot >> process with the patches. >> >> Cheers. >> Elias. >> >> 2018-08-04 16:47 GMT-03:00 Elias M. Mariani : >> > Hi Mike, >> > I saw the changes in source about this from Bryan. >> > This also hit OPENBSD_63 from a patch. >> > Shouldn't be a another patch or something ? >> > >> > Cheers. >> > Elias. >> > >> > 2018-08-01 13:23 GMT-03:00 Mike Larkin : >> >> On Wed, Aug 01, 2018 at 12:04:55AM -0300, Elias M. Mariani wrote: >> >>> (sorry, I forgot to add the list) >> >>> Here you go. >> >>> Cheers. >> >>> >> >>> 2018-07-31 20:47 GMT-03:00 Mike Larkin : >> >>> > On Tue, Jul 31, 2018 at 04:43:22PM -0700, Mike Larkin wrote: >> >>> >> On Tue, Jul 31, 2018 at 04:59:54PM -0300, Elias M. Mariani wrote: >> >>> >> > And segmentation fault after applying the patches on OPENBSD_63. >> >>> >> > Maybe is just a coincidence, according to the data: >> >>> >> > HOST: ubuntu >> >>> >> > QEMU: Running OPENBSD_63 + patches >> >>> >> > (was working OK until patched). >> >>> >> > >> >>> >> > Cheers. >> >>> >> > Elias. >> >>> >> > >> >>> >> > 2018-07-31 16:36 GMT-03:00 Elias M. Mariani >> >>> >> > : >> >>> >> > > Trying to boot in QEMU from snapshots/amd64/cd63.iso or from >> >>> >> > > snapshots/amd64/bsd.rd from the current disk: >> >>> >> > > The booting starts but the machine gets rebooted almost >> >>> >> > > immediately. >> >>> >> > > >> >>> >> > > I'm reporting this pretty bad. But is because I'm using 6.3 in >> >>> >> > > that >> >>> >> > > cloud server and just wanted to test if the snapshot was booting >> >>> >> > > correctly. QEMU is running in godsknowswhat. >> >>> >> > > I have never used QEMU myself, could someone try to reproduce ? >> >>> >> > > using cd63.iso from OPENBSD_63 gives no problems. >> >>> >> > > >> >>> >> > > Cheers. >> >>> >> > > Elias. >> >>> >> >> >>> >> >> >>> >> This may be related to the recent speculation/lfence fix that went in >> >>> >> a week or so ago. It reads an MSR that should be present on that CPU >> >>> >> (and >> >>> >> if it isn't, we won't read it). >> >>> >> >> >>> >> I have one of those same Opterons here, I'll update it to -current >> >>> >> and see >> >>> >> if I can repro this on real hardware. My guess is that kvm is failing >> >>> >> the >> >>> >> RDMSR because the knowledge of it post-dates the time that kvm was >> >>> >> built. >> >>> >> >> >>> >> -ml >> >>> >> >> >>> > >> >>> > PS, "show registers" at ddb> prompt would confirm that is indeed this >> >>> > fix, >> >>> > if you could do that and report the output it would be appreciated. >> >>> > >> >> >> >> Yes, this is related to the change I thought. I still haven't had a >> >> chance to >> >> check on real hardware yet, though. >>
Re: Snapshots in QEMU
Sorry to keep pinging this one. If you install OPENBSD_6_3 in KVM/QEMU and run syspatch and apply the LFENCE patch the machine redeems unable to boot. I think that this should be another patch to fix the problem, anyone using a OpenBSD virtual server with that config will ruin the boot process with the patches. Cheers. Elias. 2018-08-04 16:47 GMT-03:00 Elias M. Mariani : > Hi Mike, > I saw the changes in source about this from Bryan. > This also hit OPENBSD_63 from a patch. > Shouldn't be a another patch or something ? > > Cheers. > Elias. > > 2018-08-01 13:23 GMT-03:00 Mike Larkin : >> On Wed, Aug 01, 2018 at 12:04:55AM -0300, Elias M. Mariani wrote: >>> (sorry, I forgot to add the list) >>> Here you go. >>> Cheers. >>> >>> 2018-07-31 20:47 GMT-03:00 Mike Larkin : >>> > On Tue, Jul 31, 2018 at 04:43:22PM -0700, Mike Larkin wrote: >>> >> On Tue, Jul 31, 2018 at 04:59:54PM -0300, Elias M. Mariani wrote: >>> >> > And segmentation fault after applying the patches on OPENBSD_63. >>> >> > Maybe is just a coincidence, according to the data: >>> >> > HOST: ubuntu >>> >> > QEMU: Running OPENBSD_63 + patches >>> >> > (was working OK until patched). >>> >> > >>> >> > Cheers. >>> >> > Elias. >>> >> > >>> >> > 2018-07-31 16:36 GMT-03:00 Elias M. Mariani : >>> >> > > Trying to boot in QEMU from snapshots/amd64/cd63.iso or from >>> >> > > snapshots/amd64/bsd.rd from the current disk: >>> >> > > The booting starts but the machine gets rebooted almost immediately. >>> >> > > >>> >> > > I'm reporting this pretty bad. But is because I'm using 6.3 in that >>> >> > > cloud server and just wanted to test if the snapshot was booting >>> >> > > correctly. QEMU is running in godsknowswhat. >>> >> > > I have never used QEMU myself, could someone try to reproduce ? >>> >> > > using cd63.iso from OPENBSD_63 gives no problems. >>> >> > > >>> >> > > Cheers. >>> >> > > Elias. >>> >> >>> >> >>> >> This may be related to the recent speculation/lfence fix that went in >>> >> a week or so ago. It reads an MSR that should be present on that CPU (and >>> >> if it isn't, we won't read it). >>> >> >>> >> I have one of those same Opterons here, I'll update it to -current and >>> >> see >>> >> if I can repro this on real hardware. My guess is that kvm is failing the >>> >> RDMSR because the knowledge of it post-dates the time that kvm was built. >>> >> >>> >> -ml >>> >> >>> > >>> > PS, "show registers" at ddb> prompt would confirm that is indeed this fix, >>> > if you could do that and report the output it would be appreciated. >>> > >> >> Yes, this is related to the change I thought. I still haven't had a chance to >> check on real hardware yet, though.
Re: Snapshots in QEMU
Hi Mike, I saw the changes in source about this from Bryan. This also hit OPENBSD_63 from a patch. Shouldn't be a another patch or something ? Cheers. Elias. 2018-08-01 13:23 GMT-03:00 Mike Larkin : > On Wed, Aug 01, 2018 at 12:04:55AM -0300, Elias M. Mariani wrote: >> (sorry, I forgot to add the list) >> Here you go. >> Cheers. >> >> 2018-07-31 20:47 GMT-03:00 Mike Larkin : >> > On Tue, Jul 31, 2018 at 04:43:22PM -0700, Mike Larkin wrote: >> >> On Tue, Jul 31, 2018 at 04:59:54PM -0300, Elias M. Mariani wrote: >> >> > And segmentation fault after applying the patches on OPENBSD_63. >> >> > Maybe is just a coincidence, according to the data: >> >> > HOST: ubuntu >> >> > QEMU: Running OPENBSD_63 + patches >> >> > (was working OK until patched). >> >> > >> >> > Cheers. >> >> > Elias. >> >> > >> >> > 2018-07-31 16:36 GMT-03:00 Elias M. Mariani : >> >> > > Trying to boot in QEMU from snapshots/amd64/cd63.iso or from >> >> > > snapshots/amd64/bsd.rd from the current disk: >> >> > > The booting starts but the machine gets rebooted almost immediately. >> >> > > >> >> > > I'm reporting this pretty bad. But is because I'm using 6.3 in that >> >> > > cloud server and just wanted to test if the snapshot was booting >> >> > > correctly. QEMU is running in godsknowswhat. >> >> > > I have never used QEMU myself, could someone try to reproduce ? >> >> > > using cd63.iso from OPENBSD_63 gives no problems. >> >> > > >> >> > > Cheers. >> >> > > Elias. >> >> >> >> >> >> This may be related to the recent speculation/lfence fix that went in >> >> a week or so ago. It reads an MSR that should be present on that CPU (and >> >> if it isn't, we won't read it). >> >> >> >> I have one of those same Opterons here, I'll update it to -current and see >> >> if I can repro this on real hardware. My guess is that kvm is failing the >> >> RDMSR because the knowledge of it post-dates the time that kvm was built. >> >> >> >> -ml >> >> >> > >> > PS, "show registers" at ddb> prompt would confirm that is indeed this fix, >> > if you could do that and report the output it would be appreciated. >> > > > Yes, this is related to the change I thought. I still haven't had a chance to > check on real hardware yet, though.
Re: Snapshots in QEMU
(sorry, I forgot to add the list) Here you go. Cheers. 2018-07-31 20:47 GMT-03:00 Mike Larkin : > On Tue, Jul 31, 2018 at 04:43:22PM -0700, Mike Larkin wrote: >> On Tue, Jul 31, 2018 at 04:59:54PM -0300, Elias M. Mariani wrote: >> > And segmentation fault after applying the patches on OPENBSD_63. >> > Maybe is just a coincidence, according to the data: >> > HOST: ubuntu >> > QEMU: Running OPENBSD_63 + patches >> > (was working OK until patched). >> > >> > Cheers. >> > Elias. >> > >> > 2018-07-31 16:36 GMT-03:00 Elias M. Mariani : >> > > Trying to boot in QEMU from snapshots/amd64/cd63.iso or from >> > > snapshots/amd64/bsd.rd from the current disk: >> > > The booting starts but the machine gets rebooted almost immediately. >> > > >> > > I'm reporting this pretty bad. But is because I'm using 6.3 in that >> > > cloud server and just wanted to test if the snapshot was booting >> > > correctly. QEMU is running in godsknowswhat. >> > > I have never used QEMU myself, could someone try to reproduce ? >> > > using cd63.iso from OPENBSD_63 gives no problems. >> > > >> > > Cheers. >> > > Elias. >> >> >> This may be related to the recent speculation/lfence fix that went in >> a week or so ago. It reads an MSR that should be present on that CPU (and >> if it isn't, we won't read it). >> >> I have one of those same Opterons here, I'll update it to -current and see >> if I can repro this on real hardware. My guess is that kvm is failing the >> RDMSR because the knowledge of it post-dates the time that kvm was built. >> >> -ml >> > > PS, "show registers" at ddb> prompt would confirm that is indeed this fix, > if you could do that and report the output it would be appreciated. >
Snapshots in QEMU
Trying to boot in QEMU from snapshots/amd64/cd63.iso or from snapshots/amd64/bsd.rd from the current disk: The booting starts but the machine gets rebooted almost immediately. I'm reporting this pretty bad. But is because I'm using 6.3 in that cloud server and just wanted to test if the snapshot was booting correctly. QEMU is running in godsknowswhat. I have never used QEMU myself, could someone try to reproduce ? using cd63.iso from OPENBSD_63 gives no problems. Cheers. Elias.
NFS blocked if virtual machine host disappears
I'm using a virtual machine with OpenBSD, the vm hosts nfsd, the real machine (rm?) mounts the nfs with "doas mount_nfs host:/remote /local". If the vm is terminated before running "doas umount /local" /local becomes locked, running ls or umount brings the process to a full block, not responsive to Ctrl-C even. Turning down the PC is impossible also, the partition cant be unmounted (neither the parent partitions but that seems logical). I guess that replication is: Make a virtual machine running montd, portmap and nfsd. Mount in the host machine a dir from the virtual machine. Terminate the virtual machine. Try to unmount the partition on the host machine. Not adding dmesg because I dont see the point in adding junk to the thread, but if needed is not a problem. Also, I guess that the fact that I'm using a vm is not the problem, or maybe it is... Now thinking as I write... If the vm goes down, the interface that vmctl creates in the host machine disappears... might that be the cause of the problem? Thanks for the hard work as always. Elias.
Re: Bugs on Toshiba Satellite L75 Notebook
Just finished reading https://www.openbsd.org/ddb.html I will add the information later. Elias. 2018-04-27 18:06 GMT-03:00 Elias M. Mariani <marianiel...@gmail.com>: > Hi, > I found 2 bugs using -current on my notebook, both are minor bugs but > they exist, I dont have a problem myself with them but I think is > better to report them: > > 1- > Clean -current install. > Executed startx. > Screen off :( > After checking for errors in the console and in the logs I increased > the contrast and the screen came up (the contrast was so low on the > display that it seemed off). > So every time I start x have to increase the contrast from 0. > > 2- > Same case: clean -current install. > Pressing the power button or executing "shutdown -hp now" does most of > the process OK, until after the "Syncing Disks", after that the > machine panics, I dont know how to grab the information to debug with > ddb, if you can point me in the right direction I can try to pass the > error. > Again, no big problem, the disks are off so I can power-off the > Notebook by pushing the power button, just no auto-power-off. > > Thanks for the great work. > Elias. > > Environment: > System : OpenBSD 6.3 > Details : OpenBSD 6.3-current (GENERIC.MP) #13: Thu Apr 26 > 07:51:20 MDT 2018 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > > dmesg: > OpenBSD 6.3-current (GENERIC.MP) #13: Thu Apr 26 07:51:20 MDT 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 12780630016 (12188MB) > avail mem = 12385378304 (11811MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6e50 (26 entries) > bios0: vendor Insyde Corp. version "1.40" date 11/03/2014 > bios0: TOSHIBA Satellite L75-B > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP UEFI FPDT MSDM ASF! HPET APIC MCFG SLIC WDAT > SSDT BOOT ASPT DBGP SSDT SSDT SSDT SSDT DMAR > acpi0: wakeup devices P0P1(S4) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(S3) > PXSX(S4) RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) > PXSX(S4) PEG0(S4) PEGP(S4) PEG1(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz, 2594.37 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,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,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: cannot disable silicon debug > 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.2.4, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz, 2594.00 MHz > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,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,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: cannot disable silicon debug > cpu1: smt 1, core 0, package 0 > cpu2 at mainbus0: apid 2 (application processor) > cpu2: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz, 2594.01 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,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,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: cannot disable silicon debug > cpu2: smt 0, core 1, package 0 > cpu3 at mainbus0: apid 3 (application processor) > cpu3: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz, 2594.00 MHz > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDC
Bugs on Toshiba Satellite L75 Notebook
Hi, I found 2 bugs using -current on my notebook, both are minor bugs but they exist, I dont have a problem myself with them but I think is better to report them: 1- Clean -current install. Executed startx. Screen off :( After checking for errors in the console and in the logs I increased the contrast and the screen came up (the contrast was so low on the display that it seemed off). So every time I start x have to increase the contrast from 0. 2- Same case: clean -current install. Pressing the power button or executing "shutdown -hp now" does most of the process OK, until after the "Syncing Disks", after that the machine panics, I dont know how to grab the information to debug with ddb, if you can point me in the right direction I can try to pass the error. Again, no big problem, the disks are off so I can power-off the Notebook by pushing the power button, just no auto-power-off. Thanks for the great work. Elias. Environment: System : OpenBSD 6.3 Details : OpenBSD 6.3-current (GENERIC.MP) #13: Thu Apr 26 07:51:20 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 dmesg: OpenBSD 6.3-current (GENERIC.MP) #13: Thu Apr 26 07:51:20 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 12780630016 (12188MB) avail mem = 12385378304 (11811MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6e50 (26 entries) bios0: vendor Insyde Corp. version "1.40" date 11/03/2014 bios0: TOSHIBA Satellite L75-B acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI FPDT MSDM ASF! HPET APIC MCFG SLIC WDAT SSDT BOOT ASPT DBGP SSDT SSDT SSDT SSDT DMAR acpi0: wakeup devices P0P1(S4) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(S3) PXSX(S4) RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PEG0(S4) PEGP(S4) PEG1(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz, 2594.37 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,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,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: cannot disable silicon debug 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.2.4, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz, 2594.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,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,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: cannot disable silicon debug cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz, 2594.01 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,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,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: cannot disable silicon debug cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz, 2594.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,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,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: cannot disable silicon debug cpu3: smt 1, core 1, package 0 cpu4 at mainbus0: apid 4 (application processor) cpu4: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz, 2594.01 MHz cpu4:
athn: device timeout on Atheros AR9227
>Synopsis: athn: device timeout on Atheros AR9227 >Category: system >Environment: System : OpenBSD 6.3 Details : OpenBSD 6.3 (GENERIC.MP) #107: Sat Mar 24 14:21:59 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: Using a TP-LINK TL-WN851ND (Atheros AR9227) as hostap on mode 11n, wpa2-psk. Running with unbound, dhcpd and routing with pf (pretty much like the example router in the FAQ), also using apmd. The error "athn0: device timeout" comes from time to time, also the device does not broadcast when the network starts for the first time, running netstart after boot fixes that. I'm not shure if this is a bug or just an incompat with the hardware or something in the configuration, the bandwidth starts fine on the wireless AP but it seems to start to degradate as times goes by (rebooting helps...). I will try to test the device in other motherboard in a while, if someone is using this hardware as hostap fine let me know so we can discard a firmware related problem (athn-firmware-1.1p4). hostname.athn0: media autoselect mode 11n mediaopt hostap chan 6 nwid mywifi wpakey nicetry! inet 192.168.2.1 255.255.255.0 dmesg: OpenBSD 6.3 (GENERIC.MP) #107: Sat Mar 24 14:21:59 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2130313216 (2031MB) avail mem = 2058739712 (1963MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf0740 (47 entries) bios0: vendor American Megatrends Inc. version "0607" date 01/04/2007 bios0: ASUSTeK Computer INC. P5V-VM-ULTRA acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB acpi0: wakeup devices PCI0(S4) NPGS(S4) NP0S(S4) PS2K(S4) UAR1(S4) ILAN(S4) USB1(S4) USB2(S4) USB3(S4) USB4(S4) PWRB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Pentium(R) 4 CPU 3.20GHz, 3200.58 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,DTES64,MWAIT,DS-CPL,EST,CNXT-ID,CX16,xTPR,LONG,PERF,MELTDOWN cpu0: 2MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64 cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Pentium(R) 4 CPU 3.20GHz, 3199.97 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,DTES64,MWAIT,DS-CPL,EST,CNXT-ID,CX16,xTPR,LONG,PERF,MELTDOWN cpu1: 2MB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 3, 24 pins ioapic1 at mainbus0: apid 3 pa 0xfecc, version 3, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus 2 (NBPG) acpiprt3 at acpi0: bus 3 (NBP0) acpiprt4 at acpi0: bus 4 (P0P7) acpicpu0 at acpi0: C1(@1 halt!), PSS acpicpu1 at acpi0: C1(@1 halt!), PSS aibs0 at acpi0 RTMP RVLT RFAN acpibtn0 at acpi0: PWRB cpu0: Enhanced SpeedStep 3200 MHz: speeds: 3200, 2800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "VIA P4M890 Host" rev 0x00 agp at pchb0 not configured pchb1 at pci0 dev 0 function 1 "VIA P4M890 Host" rev 0x00 pchb2 at pci0 dev 0 function 2 "VIA P4M890 Host" rev 0x00 pchb3 at pci0 dev 0 function 3 "VIA P4M890 Host" rev 0x00 pchb4 at pci0 dev 0 function 4 "VIA P4M890 Host" rev 0x00 "VIA P4M890 IOAPIC" rev 0x00 at pci0 dev 0 function 5 not configured pchb5 at pci0 dev 0 function 6 "VIA P4M890 Security" rev 0x00 pchb6 at pci0 dev 0 function 7 "VIA P4M890 Host" rev 0x00 ppb0 at pci0 dev 1 function 0 "VIA VT8377 AGP" rev 0x00 pci1 at ppb0 bus 1 ppb1 at pci0 dev 2 function 0 "VIA P4M890" rev 0x00: apic 3 int 3 pci2 at ppb1 bus 2 vga1 at pci2 dev 0 function 0 "NVIDIA GeForce 8400 GS" rev 0xa1 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb2 at pci0 dev 3 function 0 "VIA P4M890" rev 0x00: apic 3 int 7 pci3 at ppb2 bus 3 re0 at pci0 dev 9 function 0 "Realtek 8169" rev 0x10: RTL8169/8110SB (0x1000), apic 2 int 17, address aa:aa:aa:aa:aa:aa rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 3 athn0 at pci0 dev 10 function 0 "Atheros AR9227" rev 0x01: apic 2 int 19 athn0: AR9287 rev 2 (2T2R), ROM rev 4, address aa:aa:aa:aa:aa:aa pciide0 at pci0 dev 15 function 0 "VIA VT82C571 IDE" rev 0x07: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 76293MB, 15625 sectors wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 pciide0: channel 1 disabled (no drives) uhci0 at pci0 dev 16 function 0 "VIA VT83C572 USB" rev 0xa0: apic 2 int 20 uhci1 at pci0 dev
