Re: OpenBSD Guest under QEMU fails with pid 1 signal 11
On Thu, Aug 02, 2018 at 05:59:41PM +, Bill Zissimopoulos wrote: > Mike, thank you for your response. > > On 8/2/18, 9:07 AM, Mike Larkin wrote: > > 1. We've seen this message before (usually on APUs), but only a single > time (eg, > just one of the signal lines gets displayed). And IIRC it was a different > signal. > > The only other instance of this message that I have found online is here: > > https://github.com/yellowman/flashrd/issues/30 > > 2. In your case, the stream of messages seems to stop after some time and > boot > proceeds normally after that. > > You are right. Although I believe that I have seen it print the message > endlessly as well. > > 3. When I built the image using your script, on the second boot, I saw no > messages. > > I'm not sure what's causing the problem, can you try with 6.3 release? > (I'm > assuming you are using -current here? that's what I tested also) > > The problem happens for me with the 6.3 release (install63.iso). I have not > tested other releases. > > (I believe I tried the 6.2 release at some point, but did not complete my > testing because it needed extensive changes to the expect script.) > > 4. in my test the default install location came up as http, so your > script's > pressing of "enter" for install path hung. I had to change the default > location > in the script to be cd. > > That does not happen for me, perhaps because of the install image I use > (install63.iso). > > 5. Your customization step at the end should probably fixup /etc/ttys or > you won't be able to log in to the machine via serial (since no getty will > be spawned there). I sat there waiting for a while in qemu only to realize > the getty was waiting on the vga console, not serial. YMMV. > > You are right. I have not managed to fix serial access for OpenBSD yet, > because I focused on resolving the discussed issue first. > > My understanding is that the instructions at the following link should get > serial access fully working: > > https://www.openbsd.org/faq/faq7.html#SerCon > > Bill > > > Unfortunately, I don't have any other ideas for you as to how to stop the segvs. It is not seen on real hardware, so I'm at a loss to explain why qemu exhibits this behaviour. Perhaps try changing the cpu type with -cpu ?
Re: Support for Intel i915 video chipset
On 2018-08-03, Jay Hart wrote: > Let me add a bit more data: > > MITAC PD11BICC motherboard (running Intel Indian Bay Trail chipset I think). > > Link to motherboard manual: https://globalamericaninc.com/manuals/2809056.pdf > > Has both a DVI-I and VGA port. I have only tried the VGA port but assume same > issue if I use the > DVI-I port. > > OpenBSD 6.3 installed just fine, just can't get it boot now, so I don't think > its a BIOS setting > per se, but don't know this for a fact. > > I can't get you dmesg, else I'd post it. The info I got below was best I > could get with a cell phone. Are you intending to run it as a graphical workstation? If not, try "b -c" at the bootloader prompt, then "disable inteldrm" and "quit". That is likely to get it booting - if so, you should be able to get a dmesg. (The on-disk kernel can be edited with "config -ef /bsd"). > Jay > >> Good afternoon, >> >> I'm trying to determine the level of support in 6.3 for an i915 chipset. If >> it is not supported, >> what driver might work? >> >> I've bought a new server and can't get it to boot. >> >> Upon startup, the boot up is proceeding normally until these lines are shown: >> >> pchb0 at pci0 dev 0 function 0 "Indian Bay Trail Host" rev 0x0e >> inteldrm0 at pci0 dev 2 function o "Intel Bay Trail Video" rev 0x0e >> drm0 at Inteldrm0 >> Inteldrm0: msi >> >> At this point, the box reboots into BIOS. >> >> Any suggestions to try and get the box booting? >> >> Thanks, >> >> Jay >> >> > > >
Re: Support for Intel i915 video chipset
Let me add a bit more data: MITAC PD11BICC motherboard (running Intel Indian Bay Trail chipset I think). Link to motherboard manual: https://globalamericaninc.com/manuals/2809056.pdf Has both a DVI-I and VGA port. I have only tried the VGA port but assume same issue if I use the DVI-I port. OpenBSD 6.3 installed just fine, just can't get it boot now, so I don't think its a BIOS setting per se, but don't know this for a fact. I can't get you dmesg, else I'd post it. The info I got below was best I could get with a cell phone. Jay > Good afternoon, > > I'm trying to determine the level of support in 6.3 for an i915 chipset. If > it is not supported, > what driver might work? > > I've bought a new server and can't get it to boot. > > Upon startup, the boot up is proceeding normally until these lines are shown: > > pchb0 at pci0 dev 0 function 0 "Indian Bay Trail Host" rev 0x0e > inteldrm0 at pci0 dev 2 function o "Intel Bay Trail Video" rev 0x0e > drm0 at Inteldrm0 > Inteldrm0: msi > > At this point, the box reboots into BIOS. > > Any suggestions to try and get the box booting? > > Thanks, > > Jay > >
Re: How can I mount an USB stick during update / installation?
Felix Maschek wrote: > After upgrading my system (using bsd.rd) I get the prompt "Exit to > (S)hell, (H)alt or (R)eboot?". > > When I select S I get a shell. Now I want to mount a USB stick. when I > insert it I get the expected log message, that the device is found and > has the name "sd2". > > How can I mount this stick? "mount /dev/sd2i /mnt/stick" does not work > since there is no "/dev/sd2i". cd /dev sh MAKEDEV sd2 Device nodes don't exista on the install media; the installer creates them on the fly.
How can I mount an USB stick during update / installation?
Hi! After upgrading my system (using bsd.rd) I get the prompt "Exit to (S)hell, (H)alt or (R)eboot?". When I select S I get a shell. Now I want to mount a USB stick. when I insert it I get the expected log message, that the device is found and has the name "sd2". How can I mount this stick? "mount /dev/sd2i /mnt/stick" does not work since there is no "/dev/sd2i". What am I missing? Kind regards Felix
Support for Intel i915 video chipset
Good afternoon, I'm trying to determine the level of support in 6.3 for an i915 chipset. If it is not supported, what driver might work? I've bought a new server and can't get it to boot. Upon startup, the boot up is proceeding normally until these lines are shown: pchb0 at pci0 dev 0 function 0 "Indian Bay Trail Host" rev 0x0e inteldrm0 at pci0 dev 2 function o "Intel Bay Trail Video" rev 0x0e drm0 at Inteldrm0 Inteldrm0: msi At this point, the box reboots into BIOS. Any suggestions to try and get the box booting? Thanks, Jay
Re: How can I mount a HDD with full encryption on another system?
On Fri, Aug 03, 2018 at 12:06:41AM +0200, Felix Maschek wrote: > I've used a full encrypted HDD (created as described in the OpenBSD FAQ) on > a broken system and want to backup some data from it. > I've assembled this HDD into an external USB case and want to mount the HDD > on another system. How can I mount this HDD? Needless to say that I know the > passphrase... Find the disk: $ dmesg | grep CRYPTO sd3 at scsibus4 targ 2 lun 0: SCSI2 0/direct fixed # disklabel sd3 ... size offset fstype [fsize bsize cpg] a:488279018 64 RAID ... Unlock it: # bioctl -c C -l /dev/sd3a softraid0 ... attached as sd4 ... # disklabel sd4 ... Mount partitions: # mount /dev/sd4k /mnt/home Good luck, Erling
Re: How can I mount a HDD with full encryption on another system?
On Fri, Aug 03, 2018 at 12:06:41AM +0200, Felix Maschek wrote: > Hi! > > I've used a full encrypted HDD (created as described in the OpenBSD FAQ) on > a broken system and want to backup some data from it. > > I've assembled this HDD into an external USB case and want to mount the HDD > on another system. How can I mount this HDD? Needless to say that I know the > passphrase... > > Kind regards > Felix > See the bioctl(8) man page. The softraid(4) man page may also be helpful.
How can I mount a HDD with full encryption on another system?
Hi! I've used a full encrypted HDD (created as described in the OpenBSD FAQ) on a broken system and want to backup some data from it. I've assembled this HDD into an external USB case and want to mount the HDD on another system. How can I mount this HDD? Needless to say that I know the passphrase... Kind regards Felix
Add my web site to "support" section like "new" one
0 C France P Ile de france T Paris Z 75020 O Iglou.eu I Adrien Kara A 3/7 rue Albert Marquet M cont...@iglou.eu U https://iglou.eu/ B +33 9 72 61 63 13 X N Maintenance et déploiement d'OpenBSD sur serveur client·e·s. Configuration de services sécurisés (httpd, smtpd, pf, ...). Réalisation de scripts shell, application web et local sous OpenBSD.
Re: OpenBSD Guest under QEMU fails with pid 1 signal 11
Mike, thank you for your response. On 8/2/18, 9:07 AM, Mike Larkin wrote: 1. We've seen this message before (usually on APUs), but only a single time (eg, just one of the signal lines gets displayed). And IIRC it was a different signal. The only other instance of this message that I have found online is here: https://github.com/yellowman/flashrd/issues/30 2. In your case, the stream of messages seems to stop after some time and boot proceeds normally after that. You are right. Although I believe that I have seen it print the message endlessly as well. 3. When I built the image using your script, on the second boot, I saw no messages. I'm not sure what's causing the problem, can you try with 6.3 release? (I'm assuming you are using -current here? that's what I tested also) The problem happens for me with the 6.3 release (install63.iso). I have not tested other releases. (I believe I tried the 6.2 release at some point, but did not complete my testing because it needed extensive changes to the expect script.) 4. in my test the default install location came up as http, so your script's pressing of "enter" for install path hung. I had to change the default location in the script to be cd. That does not happen for me, perhaps because of the install image I use (install63.iso). 5. Your customization step at the end should probably fixup /etc/ttys or you won't be able to log in to the machine via serial (since no getty will be spawned there). I sat there waiting for a while in qemu only to realize the getty was waiting on the vga console, not serial. YMMV. You are right. I have not managed to fix serial access for OpenBSD yet, because I focused on resolving the discussed issue first. My understanding is that the instructions at the following link should get serial access fully working: https://www.openbsd.org/faq/faq7.html#SerCon Bill
Re: OpenBSD Guest under QEMU fails with pid 1 signal 11
On Thu, Aug 02, 2018 at 05:47:07AM +, Bill Zissimopoulos wrote: > I am trying to create OpenBSD images for use in Google Compute Engine using > an expect script [1]. The expect script is able to drive the OpenBSD > installation process successfully, but the created images fail to boot > cleanly with a long stream of "Process (pid 1) got signal 11". > > To reproduce try the following (please note that all my tests are on a macOS > host with QEMU installed): > > - Clone the GitHub project at [2] > - Assuming you have QEMU installed and install63.iso downloaded try the > command: > ./imgtool PATH/TO/install63.iso openbsd/base > - The openbsd/base expect script will boot the image and you should see the > stream of "Process (pid 1) got signal 11". If not, try running the created > image: > ./imgtool install63-base.tar.gz shared/run > > Thank you for your help. > > Bill > > [1] https://github.com/billziss-gh/pmci.img/blob/master/openbsd/base > [2] https://github.com/billziss-gh/pmci.img > I see the same thing using your script. A few observations: 1. We've seen this message before (usually on APUs), but only a single time (eg, just one of the signal lines gets displayed). And IIRC it was a different signal. 2. In your case, the stream of messages seems to stop after some time and boot proceeds normally after that. 3. When I built the image using your script, on the second boot, I saw no messages. I'm not sure what's causing the problem, can you try with 6.3 release? (I'm assuming you are using -current here? that's what I tested also) Also some more notes: 4. in my test the default install location came up as http, so your script's pressing of "enter" for install path hung. I had to change the default location in the script to be cd. 5. Your customization step at the end should probably fixup /etc/ttys or you won't be able to log in to the machine via serial (since no getty will be spawned there). I sat there waiting for a while in qemu only to realize the getty was waiting on the vga console, not serial. YMMV. -ml
Re: 014_amdlfence.patch breaks OpenBSD VMs on AMD systems
Mike Larkin wrote: > On Thu, Aug 02, 2018 at 09:22:53AM +0200, Nulani t'Acraya wrote: > > Hello, > > > > Something similar also appears to also be affecting bhyve, at least on an > > AMD Opteron 4228 HE. The error produced is different depending on > > whether bhyve is instructed to ignore accessed to model specific registers > > that are not implemented in the current CPU. I haven't had to have that flag > > toggled previously. I've included the dmesg and trace from both setups > > below. > > > > A snapshot of -current with a build date of 1533181438 - Thu Aug 2 03:43:58 > > UTC 2018 boots successfully with ignore_bad_msr set to on. I'm not entirely > > sure if Bryan's patch will have made it into that snapshot or not, but > > if it has, > > it appears to also be fixing the issue on bhyve. Thanks! > > > > Sincerely, > > Nulani. > > > > The problem is not ignoring access to bad MSRs. > > The problem is that these hypervisors dont know that the MSR we are accessing > is > indeed a real, valid MSR. And then they panic. Indeed. AMD said their hardware has this chicken bit in a specific MSR. It was previously undocumented. The hypervisors have a whitelist of MSR, and this MSR is not listed, and instead blocked. The hypervisors need to be updated. The people who run that code can tell them to do so.
Re: 014_amdlfence.patch breaks OpenBSD VMs on AMD systems
On Thu, Aug 02, 2018 at 09:22:53AM +0200, Nulani t'Acraya wrote: > Hello, > > Something similar also appears to also be affecting bhyve, at least on an > AMD Opteron 4228 HE. The error produced is different depending on > whether bhyve is instructed to ignore accessed to model specific registers > that are not implemented in the current CPU. I haven't had to have that flag > toggled previously. I've included the dmesg and trace from both setups below. > > A snapshot of -current with a build date of 1533181438 - Thu Aug 2 03:43:58 > UTC 2018 boots successfully with ignore_bad_msr set to on. I'm not entirely > sure if Bryan's patch will have made it into that snapshot or not, but > if it has, > it appears to also be fixing the issue on bhyve. Thanks! > > Sincerely, > Nulani. > The problem is not ignoring access to bad MSRs. The problem is that these hypervisors dont know that the MSR we are accessing is indeed a real, valid MSR. And then they panic. -ml > ### 6.3 without ignore_bad_msr ### > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org > > OpenBSD 6.3 (GENERIC) #7: Sun Jul 29 11:30:47 CEST 2018 > r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > real mem = 1056964608 (1008MB) > avail mem = 1019158528 (971MB) > warning: no entropy supplied by boot loader > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf101f (9 entries) > bios0: vendor BHYVE version "1.00" date 03/14/2014 > bios0: bhyve BHYVE > acpi0 at bios0: rev 2 > acpi0: sleep states S5 > acpi0: tables DSDT APIC FACP HPET MCFG > acpi0: wakeup devices > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Opteron(tm) Processor 4228 HE, 2800.42 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,XOP,SKINIT,WDT,FMA4,ITSC > cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB > 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache > cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative > cpu0: DTLB 32 4KB entries fully associative, 32 4MB entries fully associative > kernel: protection fault trap, code=0 > Stopped at 0x81219c59: wrmsr > ddb> trace > 81219c59(80031700,81a7fff0,81a7d028,81c > 06a58,80031724,0) at 0x81219c59 > 81008d2e(80023100,81c06a58,80031700,81a > 7d000,81008d2e,81c069b0) at 0x81008d2e > 813618b8(0,800232c4,80023298,800232c4,8 > 1c06a38,816c51a0) at 0x813618b8 > 816c4c36(80020400,81c06b60,81ab3f38,800 > 31200,80031224,0) at 0x816c4c36 > 813618b8(81c06b60,80020400,80020470,800 > 20460,80023280,8100d040) at 0x813618b8 > 8100c571(80023180,81c06c50,81a811a8,800 > 20400,80020424,0) at 0x8100c571 > 813618b8(800014a67023,80023180,3c,104,800014a67042, > 8140b6f0) at 0x813618b8 > 8140a766(80023100,81c06d88,81aa1ea8,800 > 23180,800231a4,0) at 0x8140a766 > 813618b8(81c06d88,80023100,81a8ba98,800 > 23100,80023124,811a9830) at 0x813618b8 > 811a95a1(0,0,0,81c06db0,81c06e20,300010) at > 0xf > fff811a95a1 > 813618b8(0,81827131,81a9fd8a,81c06e78,b28,0) > at > 0x813618b8 > 81361a53(0,0,0,0,81c8,0) at 0x81361a53 > 8101187b(0,0,8101187b,81c06ef0,0,0) at > 0x810118 > 7b > 8116b8c3(0,0,0,0,8116b8c3,81c06f20) at > 0x8116b8 > c3 > end trace frame: 0x0, count: -14 > ddb> ps >PID TID PPIDUID S FLAGS WAIT COMMAND > *0 0 -1 0 7 0x10200swapper > > ###6.3 with ignore_bad_msr### > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org > > OpenBSD 6.3 (GENERIC) #7: Sun Jul 29 11:30:47 CEST 2018 > r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > real mem = 1056964608 (1008MB) > avail mem = 1019158528 (971MB) > warning: no entropy supplied by boot loader >
Re: 014_amdlfence.patch breaks OpenBSD VMs on AMD systems
On Wed, Aug 01, 2018 at 03:46:25PM +0200, Elmer Skjødt Henriksen wrote: > After installing the 014_amdlfence patch released yesterday for 6.3, my > OpenBSD VM crashes on boot. It's running under KVM on a Linux box (Ubuntu > 18.04 w/ kernel 4.15) on an AMD Ryzen 7 1700 (microcode 0x8001137). > I suppose this would also happen on vmm(4) and bhyve, however I don't have > any such AMD hosts available for testing. > > It occurs both using libvirt's "EPYC" CPU model and using "host-passthrough" > (i.e. no virtual CPU model), but the "core2duo" CPU model works fine. > > I guess not many people are running OpenBSD as a VM, and even less on AMD > hardware. But still, a syspatch leaving the system unable to boot is > probably not a good thing. :) > Perhaps there are some differences between Ryzen and Threadripper then. I run Ubuntu 18.04 on a 1950X Threadripper and a couple of OpenBSD hosts under libvirt/KVM and it works well here: # uname -a Linux 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux EPYC AMD OpenBSD 6.3 (GENERIC.MP) #7: Sun Jul 29 11:43:12 CEST 2018 r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4278054912 (4079MB) avail mem = 4141334528 (3949MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xbc60 (17 entries) bios0: vendor SeaBIOS version "1.10.2-1ubuntu1" date 04/01/2014 bios0: QEMU Standard PC (i440FX + PIIX, 1996) acpi0 at bios0: rev 0 acpi0: sleep states S5 acpi0: tables DSDT FACP APIC acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD EPYC Processor, 3400.37 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,XSAVEOPT,XSAVEC,XGETBV1 cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 cache cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 1000MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD EPYC Processor, 3399.97 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,XSAVEOPT,XSAVEC,XGETBV1 cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 cache cpu1: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu1: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD EPYC Processor, 3399.98 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,XSAVEOPT,XSAVEC,XGETBV1 cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 cache cpu2: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu2: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD EPYC Processor, 3399.98 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,XSAVEOPT,XSAVEC,XGETBV1 cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 cache cpu3: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu3: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu4 at mainbus0: apid 4 (application processor) cpu4: AMD EPYC Processor, 3399.97 MHz cpu4:
Re: ***SPAM*** Re: nmap on routed ip4 networks, openbsd/pf or package/port issue?
On 08-01 15:08, Henrik Engmark wrote: >> So I set up a new 6.3 with the sole purpose of nmapping, since my older >> OpenBSDs is coremapping on me with nmap. >>[] >> On to the problem, I scan my local LAN with the following: >> nmap -Pn -A -v -v --send-eth -e em0 -stylesheet somestylesheet -oA >>/tmp/nmapout 192.168.1.0/24 This works fine, every time i try. Takes about >>an hour. However, when I try it on a remote routed net like so: >> nmap -Pn -A -v -v --send-eth -e em1 -stylesheet somestylesheet -oA >>/tmp/nmapout 10.20.30.192/26 >> >> nmap stops doing anything after a minute or so, it goes to 0% cpu and stays >> there. I waited at least 24 hours without any sign of life. >> top tells me nmap is WAIT/bpf after those first couple of minutes. I am not >> sure what that means exactly, but I figured maybe something with pf, so I >> disabled pf alltogether and tried again, with the same result. > >I am curious what you learn as I have seen similar behavior. I've been >nmapping a printer on my local network, trying different things, and nmap >freezes for me after a short or long time. > >Strangely though, it seems to ~ "unfreeze" if I start another nmap instance, >probing the same address, in a separate terminal window. >Sometimes I have to kill and restart that other instance as it freezes too, >but this workaround has allowed me to continue at least. > >I am on 6.3 stable with latest syspatch. > Indeed starting several nmap sessions against the same subnet seems to make things a lot better. They somehow seem to keep eachother alive. This might just be me who is too inexperienced with tweaking nmap, but I don't run in to this issue on other platforms. Does anyone know where best to pursue this problem? The ports list, the maintainer directly or not at all perhaps?
Re: upgrading to a snapshot; what to do with ports tree?
On 2018/08/02 10:16, Rudolf Sykora wrote: > > Use cvs. > > Ok. I just tried to follow the table at > https://www.openbsd.org/faq/ports/ports.html > under > Fetching the ports tree > where I understood the table in the sense to download the tar. > (At that point I haven't realized that there seems to exist just > one snapshot [not a series of them in time], so I wanted to have the ports > tree just right for the snapshot. If we only consider the newest > snapshot, I understand that using cvs and its -current branch is > just nearly the same.) I think it's fairly pointless to have a ports.tar.gz for -current. People following current and using it for ports development are expected to keep up with cvs anyway. People not using it for ports development mostly don't need a ports tree and are better served with snapshot packages instead. (The main exception to this is if you need to use things from ports where we aren't allowed to distribute packages so you need to build them yourself.) There's no ports.tar.gz which can be guaranteed to be "just right" for any given snapshot. They are produced separately. > > No need to remove the existing files. > > No need to remove if you use cvs. Right? > But if tar is used, then the removal is needed, no? > Without it some old (say removed, no longer valid ports) > would remain. ports.tar.gz is just a tarred-up CVS checkout. You can update it with CVS using the usual flags (-Pd), this will remove old directories and add new ones as needed. If you're downloading the whole ports.tar.gz tree again to unpack then yes you will need to remove old files first, but I wouldn't recommend that.
Re: upgrading to a snapshot; what to do with ports tree?
On 2018-08-02, Rudolf Sykora wrote: > Hello, > > when I switch to a recent snapshot, I can also download ports.tar.gz > related to it. > Should I just first completely remove the old tree > (rm -rf /usr/ports), or should I keep it and untar the > ne ports.tar.gz over it? > > (I guess the first, but...) > > Thanks > Ruda > > Use cvs. See http://www.openbsd.org/anoncvs.html and note the "changing the server" section if your existing one came from ports.tar.gz. No need to remove the existing files.
Re: upgrading to a snapshot; what to do with ports tree?
On Thu, Aug 02, 2018 at 09:14:10AM +0200, Rudolf Sykora wrote: > when I switch to a recent snapshot, I can also download ports.tar.gz > related to it. If you already have a ports tree, cvs up from a nearby mirror is likely faster. I tend to use pretty much the commands you find at http://www.openbsd.org/anoncvs.html with adjustments to use the most-local mirror (for me thats the eu one). And of course for most ports or packages, pkg_add -u is probably all you need. If you suspect your package information could be off in some way, pkg_check is useful too. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: 014_amdlfence.patch breaks OpenBSD VMs on AMD systems
Hello, Something similar also appears to also be affecting bhyve, at least on an AMD Opteron 4228 HE. The error produced is different depending on whether bhyve is instructed to ignore accessed to model specific registers that are not implemented in the current CPU. I haven't had to have that flag toggled previously. I've included the dmesg and trace from both setups below. A snapshot of -current with a build date of 1533181438 - Thu Aug 2 03:43:58 UTC 2018 boots successfully with ignore_bad_msr set to on. I'm not entirely sure if Bryan's patch will have made it into that snapshot or not, but if it has, it appears to also be fixing the issue on bhyve. Thanks! Sincerely, Nulani. ### 6.3 without ignore_bad_msr ### Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.3 (GENERIC) #7: Sun Jul 29 11:30:47 CEST 2018 r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 1056964608 (1008MB) avail mem = 1019158528 (971MB) warning: no entropy supplied by boot loader mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf101f (9 entries) bios0: vendor BHYVE version "1.00" date 03/14/2014 bios0: bhyve BHYVE acpi0 at bios0: rev 2 acpi0: sleep states S5 acpi0: tables DSDT APIC FACP HPET MCFG acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Opteron(tm) Processor 4228 HE, 2800.42 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,HV,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,XOP,SKINIT,WDT,FMA4,ITSC cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu0: DTLB 32 4KB entries fully associative, 32 4MB entries fully associative kernel: protection fault trap, code=0 Stopped at 0x81219c59: wrmsr ddb> trace 81219c59(80031700,81a7fff0,81a7d028,81c 06a58,80031724,0) at 0x81219c59 81008d2e(80023100,81c06a58,80031700,81a 7d000,81008d2e,81c069b0) at 0x81008d2e 813618b8(0,800232c4,80023298,800232c4,8 1c06a38,816c51a0) at 0x813618b8 816c4c36(80020400,81c06b60,81ab3f38,800 31200,80031224,0) at 0x816c4c36 813618b8(81c06b60,80020400,80020470,800 20460,80023280,8100d040) at 0x813618b8 8100c571(80023180,81c06c50,81a811a8,800 20400,80020424,0) at 0x8100c571 813618b8(800014a67023,80023180,3c,104,800014a67042, 8140b6f0) at 0x813618b8 8140a766(80023100,81c06d88,81aa1ea8,800 23180,800231a4,0) at 0x8140a766 813618b8(81c06d88,80023100,81a8ba98,800 23100,80023124,811a9830) at 0x813618b8 811a95a1(0,0,0,81c06db0,81c06e20,300010) at 0xf fff811a95a1 813618b8(0,81827131,81a9fd8a,81c06e78,b28,0) at 0x813618b8 81361a53(0,0,0,0,81c8,0) at 0x81361a53 8101187b(0,0,8101187b,81c06ef0,0,0) at 0x810118 7b 8116b8c3(0,0,0,0,8116b8c3,81c06f20) at 0x8116b8 c3 end trace frame: 0x0, count: -14 ddb> ps PID TID PPIDUID S FLAGS WAIT COMMAND *0 0 -1 0 7 0x10200swapper ###6.3 with ignore_bad_msr### Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2018 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.3 (GENERIC) #7: Sun Jul 29 11:30:47 CEST 2018 r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 1056964608 (1008MB) avail mem = 1019158528 (971MB) warning: no entropy supplied by boot loader mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf101f (9 entries) bios0: vendor BHYVE version "1.00" date 03/14/2014 bios0: bhyve BHYVE acpi0 at bios0: rev 2 acpi0: sleep states S5 acpi0: tables DSDT APIC FACP HPET MCFG acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Opteron(tm)
upgrading to a snapshot; what to do with ports tree?
Hello, when I switch to a recent snapshot, I can also download ports.tar.gz related to it. Should I just first completely remove the old tree (rm -rf /usr/ports), or should I keep it and untar the ne ports.tar.gz over it? (I guess the first, but...) Thanks Ruda
