pkg_add - error while reading header / read short file / gzheader truncated
Hello Misc, I am configuring a couple of laptops for my kids, i had installed 70 with i3 and gcompris in them, its been a while since the last update so i decided to make a fresh install. So I installed 74 in both of them, used the autoinstall so the process was straightforward as always, rebooted, hw_update, syspatch, everything as expected. The problem comes when trying to install a package, i am trying just to of them: feh and gcompris, in both laptops, and i get the following errors, they are several since i do a few tries and then the problem goes and comes at different packages pkg_add: Ustar [package name, it is different every try, meaning lcms2-2.15.tgz, gstreamer, libass-] [?]: Error while reading header https://cdn.openbsd.org/pub/OpenBSD/7.4/packages/amd64/lame-3.100p1.tgz: Read short file My configuration are: 1 laptop, re0, trying pkg_add feh 1 laptop, iwn0, trying pkg_add gcompris both with the same results, maybe i should try in another LAN, but could it be a problem with the CDN server ? Thank you for your time, -- Manuel Solis >> Hello, I'm new to openBSD about 3 days old. and I ran into the same issue as you. I would pkg_add something and I kept getting the header message. someone on IRC helped me Simple. change the cdn to another mirror look at https://www.openbsd.org/faq/faq15.html#Mirror Basically You find a mirror probably ftp like I did go to vim or nano /etc/installurl delete the cdn add another mirror and re-run the pkg_add you might need to pkg_delete the partial and then re-run. pkg_add After all that you might need pkg_add -u to see if the new mirror fixes all the other partials Hope this helps ~ Joe B
Adding multilib target for arm-none-eabi-gcc
I'm cross-compiling for an ST Nucleo F411RE, which requires these CFLAGS: -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 On my system, 'arm-none-eabi-gcc -print-multi-directory' can't find a match for them. By comparison, on Debian, it finds 'thumb/v7e-m+fp/hard'. Is there a way for me to update the port to include more targets, and reinstall it? --- System/package information: * OpenBSD 7.2 * arm-none-eabi-gcc-linaro-7.4.2019.02p0 * arm-none-eabi-newlib-2.2.0.1p1 $ arm-none-eabi-gcc --print-multi-lib .; thumb;@mthumb fpu;@mfloat-abi=hard interwork;@mthumb-interwork fpu/interwork;@mfloat-abi=hard@mthumb-interwork thumb/interwork;@mthumb@mthumb-interwork
cdn.openbsd.org stale bsd.mp for amd64 snaps
Hello, The amd64 snapshots on cdn.openbsd.org have a stale bsd.mp file, which is making sysupgrades fail. The other files are up-to-date. ftp.openbsd.org has the correct bsd.mp, so it appears to be a caching issue with Fastly. Might need to force a refresh? Thanks, -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
MNT Pocket Reform - OpenBSD support "in development"
https://mntre.com/media/reform_md/2022-06-20-introducing-mnt-pocket-reform.html Looks like a fun little machine, and they claim OpenBSD support is "in development." I'm curious, have they contributed any code or resources to make OpenBSD run on this device? I'd be more inclined to buy one if they are actually contributing to the project. Thanks, -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
Re: OpenBSD and multitasking
> Hello, > > I use OpenBSD amd64 snapshots on the following dmesg hardware. > The download rate on a browser was slow and I figured out with some > memory mapped partition that disk transfer rate was slow. > I can bear this since I'm not into large file transfer business. But > here is another interesting fact: each time my disk is used by some > file transfer, all the running applications, mostly GUI based are > stalling - that includes mostly chromium ( even if it is not chromium > that it does the disk data transfer). > > My questions are: is something incorrectly set up on my computer, > regarding the multitasking? > I understand disk operations are slow, but may I say that kernel is > dragged in that slow transfer too (no DMA, no cache, etc.)? > Does this happens to all users, but since there are more powerful > configuration involved the delay is not so noticeable? > > I know it is hard to project this, but can someone give me a hint > about a minimum hardware to allow using chromium with no delays, > please? > I know, it should be advisable to get the maximum performance > hardware, but i'm not in that case. > sd0 at scsibus1 targ 0 lun 0: > naa.5000c5006520feaf > sd0: 238475MB, 512 bytes/sector, 488397168 sectors You're running on a Seagate 7200 RPM spinning disk. Migrate to an SSD. Literally any SSD. I don't know where you are, but here, an equivalent size generic SATA SSD costs $40 USD and will be exponentially faster for random read/write and IOPS. Trying to run heavy modern desktop applications like Chromium from a spinning disk is an exercise in masochism. You're also running Chromium with 8 GB of RAM, so it's entirely possible you're running into swap, which will REALLY kill your performance, especially on a spinning disk... -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
syspatch on raspberry pi 3. new kernel?
I just ran syspatch on my Raspberry Pi 3 running OpenBSD 7.0 and the patches initially appeared to have been applied successfully, including creating a new kernel and printing the message to reboot to use the new kernel. Upon reboot, motd, dmesg, and "sysctl kern.version" still report what I believe to be the original kernel: OpenBSD 7.0 (GENERIC) #1280: Thu Sep 30 16:31:07 MDT 2021 dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC That said, the new /bsd (and /bsd.booted) are dated today, as would be expected following syspatch. The result of "sha256 /bsd" matches the data in /var/db/kernel.SHA256 (file also dated today as would be expected). What else? I have also run "syspatch -R" to remove the updates, rebooted, then ran syspatch again with the same results. And it seems that /etc/motd is not being updated on boot on this system as I think usually happens. /var/run/dmesg.boot does appear to be updated with each boot. /usr/share/relink/kernel/GENERIC.MP/relink.log appears normal: (SHA256) /bsd: OK LD="ld" sh makegap.sh 0xd4d4d4d4 gapdummy.o ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o ${OBJS} textdatabss dec hex 10566181611208 829392 12006781b7357d mv newbsd newbsd.gdb ctfstrip -S -o newbsd newbsd.gdb rm -f bsd.gdb mv -f newbsd bsd install -F -m 700 bsd /bsd && sha256 -h /var/db/kernel.SHA256 /bsd Kernel has been relinked and is active on next reboot. SHA256 (/bsd) = 1e457ddd75e56de0b8cc01607a5d0be6903be07ee0c2baeb440e823a253e68a0 Running syspatch on two other systems (an old Alix/i386 and a vm at vultr.com) resulted in expected results: OpenBSD 7.0 (GENERIC) #1: Fri Oct 29 12:02:30 MDT 2021 r...@syspatch-70-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC OpenBSD 7.0 (GENERIC) #1: Fri Oct 29 12:02:41 MDT 2021 r...@syspatch-70-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC Any ideas will be greatly appreciated. Am I missing any steps here? Thanks, Joe Following is the latest dmesg from this rpi3: OpenBSD 7.0 (GENERIC) #1280: Thu Sep 30 16:31:07 MDT 2021 dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC real mem = 956735488 (912MB) avail mem = 894844928 (853MB) random: boothowto does not indicate good seed mainbus0 at root: Raspberry Pi 3 Model B Rev 1.2 cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4 cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu0: 512KB 64b/line 16-way L2 cache cpu0: CRC32,ASID16 apm0 at mainbus0 efi0 at mainbus0: UEFI 2.8 efi0: Das U-Boot rev 0x20210100 simplefb0 at mainbus0: 656x416, 32bpp wsdisplay0 at simplefb0 mux 1 wsdisplay0: screen 0-5 added (std, vt100 emulation) "system" at mainbus0 not configured "axi" at mainbus0 not configured simplebus0 at mainbus0: "soc" bcmclock0 at simplebus0 bcmmbox0 at simplebus0 bcmgpio0 at simplebus0 bcmaux0 at simplebus0 bcmdmac0 at simplebus0: DMA0 DMA2 DMA4 DMA5 DMA8 DMA9 DMA10 bcmintc0 at simplebus0 bcmrng0 at simplebus0 pluart0 at simplebus0: console bcmsdhost0 at simplebus0: 250 MHz base clock sdmmc0 at bcmsdhost0: 4-bit, sd high-speed, mmc high-speed, dma dwctwo0 at simplebus0 bcmdog0 at simplebus0 bcmtemp0 at simplebus0 "local_intc" at simplebus0 not configured sdhc0 at simplebus0 sdhc0: SDHC 3.0, 200 MHz base clock sdmmc1 at sdhc0: 4-bit, sd high-speed, mmc high-speed simplebus1 at simplebus0: "firmware" "clocks" at simplebus1 not configured "expgpio" at simplebus1 not configured "power" at simplebus0 not configured "mailbox" at simplebus0 not configured "gpiomem" at simplebus0 not configured "fb" at simplebus0 not configured "vcsm" at simplebus0 not configured "virtgpio" at simplebus0 not configured "clocks" at mainbus0 not configured "phy" at mainbus0 not configured "arm-pmu" at mainbus0 not configured agtimer0 at mainbus0: 19200 kHz "leds" at mainbus0 not configured "fixedregulator_3v3" at mainbus0 not configured "fixedregulator_5v0" at mainbus0 not configured "bootloader" at mainbus0 not configured dt: 445 probes usb0 at dwctwo0: USB revision 2.0 sdmmc0: can't enable card uhub0 at usb0 configuration 1 interface 0 "Broadcom DWC2 root hub" rev 2.00/1.00 addr 1 uhub1 at uhub0 port 1 configuration 1 interface 0 "Standard Microsystems product 0x9514" rev 2.00/2.00 addr 2 bwfm0 at sdmmc1 function 1 manufacturer 0x02d0, product 0xa9a6 at sdmmc1 function 2 not configured smsc0 at uhub1 port 1 configuration 1 interface 0 "Standard Microsystems SMSC9512/14" rev 2.00/2.00 addr 3 smsc0: address b8:27:eb:8b:a1:c7 ukphy0 at smsc0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x0001f0, model 0x000c umass0 at uhub1 port 5 configuration 1 interface 0 "Sa
Re: httpd(8) - PHP: More details in error log
On 2021-10-07 18:28, J. K. wrote: Hi, I have a question to OpenBSD's httpd and PHP. Don't know if this is httpd related or PHP. With the default settings it's hard to debug error with my PHP script, because under /var/www/logs/error.log there is no timestamp or the requested URI. Is there a configuration for httpd or PHP to get more details in the error log? Thanks in advance. BTW: This is my second mail with the same context on this list. But had some troubles with my domain. Kind regards, J. K. My apologies as I am not really answering your question, but here goes. My OpenBSD machine running httpd is solely for learning, and it is low volume. To simplify debugging, I log both access and errors to /var/www/logs/error.log with the following entries in /etc/httpd.conf log access "error.log" log error "error.log" log style forwarded The access information tells me about URI, timestamp, browser/agent, things of that nature. Along with the errors that are logged in the same file, I then can easily associate a PHP error with a URI or timestamp. My php and php-fpm files are unchanged from the defaults. My guess is there are options that can be set in /etc/php-8.0.ini but I have not checked nor made any changes to that file. (I have php/fpm 8.0 installed on my OpenBSD 6.9 system; you might have different versions installed) Anyway, this might be helpful for you in the short term -- until you are able to more correctly log the information you need. -- Joe Barnett
Re: 4K display, teeny-tiny things
> Picked up a 4K display (LG 27UPS650) and it's gorgeous. Bright colors, > crisp, lovely. The console fonts and some application fonts are now > dialed in WRT size. > > But application menu bars have tiny icons and tiny titles, and their > man pages don't address that. Do those settings live in libraries I'm > not used to tweaking? > > -- > > Edward Ahlsen-Girard > Ft Walton Beach, FL Hi Ed, The Arch Linux Wiki page on HiDPI is a good resource for this: https://wiki.archlinux.org/title/HiDPI Personally, I am using the following settings in my .Xresources file to scale things to a usable size and get a mouse pointer I can actually see (I'm using a 4k 27" display as well): Xft.dpi: 144 Xcursor.size: 32 Xcursor.theme: Adwaita Hope this helps! -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
Re: MALLOC_STATS [was: Clang sanitizer support]
Otto Moerbeek wrote: > yeah, MALLOC_STATS is not well maintained... What's the relation between the MALLOC_STATS code currently in -stable, and the code in your mdump [0] project? Are you experimenting with different approaches? BTW, thanks for your work on this. 0: https://github.com/omoerbeek/mdump
Re: MALLOC_STATS [was: Clang sanitizer support]
Omar Polo wrote: > not tried, but compiles :) Your patch made it compile for me too. With that change I was able to run through the steps in https://www.drijf.net/malloc/ and detect memory leaks! Thank you. What's the process to get your change applied to -current? Should it be submitted to the tech@ list?
Re: MALLOC_STATS [was: Clang sanitizer support]
Omar Polo wrote: > There's a built-in mechanisms to check for memory leaks: > > https://www.drijf.net/malloc/ > > don't know if it still applies, I tried only once and was like a couple > of years ago (if not more). Thanks for the tip, Omar. I just tried compiling malloc.c with MALLOC_STATS defined, but I got a compiler error: clang -O2 -pipe -g -Wimplicit -I/usr/src/lib/libc/include -I/usr/src/lib/libc/hidden \ -D__LIBC__ -Werror-implicit-function-declaration -include namespace.h \ -Werror=deprecated-declarations -DAPIWARN -DYP -I/usr/src/lib/libc/yp\ -I/usr/src/lib/libc -I/usr/src/lib/libc/gdtoa \ -I/usr/src/lib/libc/arch/amd64/gdtoa -DINFNAN_CHECK -DMULTIPLE_THREADS \ -DNO_FENV_H -DUSE_LOCALE -I/usr/src/lib/libc -I/usr/src/lib/libc/citrus \ -DRESOLVSORT -DFLOATING_POINT -DPRINTF_WIDE_CHAR -DSCANF_WIDE_CHAR -DFUTEX -MD \ -MP -c /usr/src/lib/libc/stdlib/malloc.c -o malloc.o /usr/src/lib/libc/stdlib/malloc.c:1613:14: error: use of undeclared identifier 'd' STATS_SUB(d->malloc_used, roldsz - rnewsz); ^ 1 error generated. Malloc source version: $OpenBSD: malloc.c,v 1.270 2021/04/09 06:05:21 otto Exp $ System: 6.9 stable
Re: Clang sanitizer support
On Fri, Jan 8, 2021, at 5:40 PM, Joe Nelson wrote: > Hi all, I'd like to use Clang's AddressSanitizer and ThreadSanitizer > on my OpenBSD development machine. Following up on this, looks like MALLOC_OPTIONS can help me detect use-after-free and double free errors. What I'm missing is a way to detect memory leaks in my programs. Any tips?
Re: The simplest full cray data core with 3 cpu's and a physics hack that makes it work
> On 2 Apr 2021, at 14:17, Benjamin Baier wrote: > > GPT-3 gone wild, or what? Definitely to late for Aprilfools-day. > If it’s GPT-3, it’s slipping.
Installing across two SSDs, encrypted
I'd like to install obsd on a laptop that has one built-in 128GB SSD, and a 1TB SATA SSD added in a separate bay. Was thinking of putting the system files on the small drive, and /home, /var, /tmp, and /usr/local on the big one. I'd like to use full-disk encryption for the big drive. Two questions. First, will the installer set up the partitions across the drives for me, or do I need to do a custom procedure with disklabel? Second, how do I get the OS to prompt me during startup for a passphrase, and mount the encrypted drive? (It's not the primary drive with the OS on it, which seems nonstandard.) Thanks for any help.
Clang sanitizer support
Hi all, I'd like to use Clang's AddressSanitizer and ThreadSanitizer on my OpenBSD development machine. However, the Clang 10 documentation lists OpenBSD support for only the UndefinedBehaviorSanitizer. Does anyone know how hard it would be to port them? Are they absent because nobody really cares about them, or is it because of a significant technical challenge to get them on OpenBSD? Also, are there alternatives to these sanitizers? Valgrind? Running clang on another OS in vmm(4)? I tried the valgrind package but it segfaulted immediately when I ran it early last year. OS support for sanitizers, as reported by the docs: AddressSanitizer * Android ARM * FreeBSD i386/x86_64 (tested on FreeBSD 11-current) * Linux i386/x86_64 (tested on Ubuntu 12.04) * NetBSD i386/x86_64 * Windows 8.1+ (i386/x86_64) * iOS Simulator * macOS 10.7 - 10.11 (i386/x86_64) ThreadSanitizer * Android aarch64, x86_64 * Darwin arm64, x86_64 * FreeBSD * Linux aarch64, x86_64, powerpc64, powerpc64le * NetBSD MemorySanitizer * FreeBSD * Linux * NetBSD UndefinedBehaviorSanitizer * Android * FreeBSD * Linux * NetBSD * OpenBSD * Windows * macOS
Re: AMD Ryzen
On 2020-06-23 08:56, Gregory Edigarov wrote: Hello, Can somebody tell me overall impressions/success stories of those systems? I am thinking of buying this system as my next desktop for OpenBSD of course, so please share. Most interesting would be dmesgs of some working configurations. Thanks a lot in advance -- With best regards, Gregory Edigarov I have a Ryzen 3 3200G sitting on an ASRock B450M-HDV R4.0 with 16GB RAM, and it seems to run OpenBSD (6.7) very well. I added Window Maker via packages, along with a few others such as firefox-esr, pidgin, qgis, postgresql (both server and client), and a few others, again all from packages. Bear in mind I usually use OpenBSD for network devices rather than on the desktop, but my experiment so far with the above system and config has been very positive -- very stable and responsive when booted into the graphical environment. This machine has no wifi capability, so I cannot comment on that, and I do not have speakers attached, so cannot comment on sound support. This CPU is a somewhat new-ish model with built-in Radeon Vega graphics which gave fits to several Linux distros*, but which seems to work right out of the box with OpenBSD 6.7. *latest Debian, and latest Xubuntu experienced trouble on this machine when in graphical mode, though the latest regular Ubuntu does work nicely with this machine. Good luck, Joe dmesg: OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun 4 09:55:08 MDT 2020 r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 14941401088 (14249MB) avail mem = 14475939840 (13805MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xe6cc0 (24 entries) bios0: vendor American Megatrends Inc. version "P3.70" date 11/14/2019 bios0: ASRock B450M-HDV R4.0 acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT SSDT MCFG AAFT HPET UEFI SSDT CRAT CDIT SSDT SSDT WSMT acpi0: wakeup devices GPP0(S4) GPP2(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) GP17(S4) XHC0(S4) XHC1(S4) GP18(S4) GPP1(S4) PTXH(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 3 3200G with Radeon Vega Graphics, 3593.83 MHz, 17-18-01 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,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: AMD Ryzen 3 3200G with Radeon Vega Graphics, 3593.21 MHz, 17-18-01 cpu1: 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,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 0, core 2, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: AMD Ryzen 3 3200G with Radeon Vega Graphics, 3593.21 MHz, 17-18-01 cpu2: 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,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 1, package 0 cpu3 a
Re: OpenBSD Readonly File System
On 2020-06-09 00:59, Vertigo Altair wrote: Hi Misc, I have a firewall device and I'm using OpenBSD on it. There is an electricity problem where the device runs. Therefore, I have to run the "fsck -y" command regularly at startup due to the electricity problem. To overcome this, I want to use readonly file system. I know there are some projects like "resflash", but I want to do that manually. I have hacked and slashed my way to this kind of configuration for my firewall/gateway and a few other machines -- and with what appears to be good results. Please understand this is almost certainly not supported by the project. I have outlined this at the following URL: https://www.mr72.com/readonlyfs.html I hope this helps. Any feedback will be greatly appreciated. Good luck! Joe My partitions like this; vertigo# df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/sd0a 3.9G489M3.2G13%/ /dev/sd0g 91.8G1.0G 86.2G 1%/mypartition /dev/sd0d 989M 12.0K940M 0%/tmp /dev/sd0f 3.9G1.7G2.0G46%/usr /dev/sd0e 3.9G 46.9M3.6G 1%/var I want to / and /usr as readonly, I updated /etc/fstab and I made / and /usr readonly; vertigo# cat /etc/fstab ec347fefe8d05509.b none swap sw ec347fefe8d05509.a / ffs ro 1 1 ec347fefe8d05509.g /mypartition ffs rw,nodev,nosuid 1 2 ec347fefe8d05509.d /tmp ffs rw,nodev,nosuid 1 2 ec347fefe8d05509.f /usr ffs ro,wxallowed,nodev 1 2 ec347fefe8d05509.e /var ffs rw,nodev,nosuid 1 2 On startup following errors comming from /etc/rc; I think errors about /etc/motd are not so important, but are the errors coming from /etc/tty* can cause any problems? If my method is not correct, what is the best way to do this? OpenBSD/amd64 BOOTX64 3.50 boot> booting hd0a:/bsd: 12957000+2753552+327712+0+708608 [807408+128+1024872+749630]=0x1271a18 entry point at 0x1001000 [ using 2583064 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2020 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun 4 09:55:08 MDT 2020 r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4151607296 (3959MB) avail mem = 4013170688 (3827MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebf10 (14 entries) bios0: vendor American Megatrends Inc. version "BAR3NA05" date 07/23/2018 bios0: NF533 NF533 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG LPIT HPET SSDT SSDT SSDT UEFI acpi0: wakeup devices XHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(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) Celeron(R) CPU J1900 @ 1.99GHz, 2000.37 MHz, 06-37-09 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 1MB 64b/line 16-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 83MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.01 MHz, 06-37-09 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.03 MHz, 06-37-09 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu2: 1MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.01 MHz, 06-37-09 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG
Re: relayd + httpd + Django/Rails?
Now I feel dumb. Didn't need relayd at all - just the "fastcgi" option inside a httpd server block. Jesus christ. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday 23. April 2020 kl. 04:17, Joe Ansbach wrote: > Hi, > > I got this VPS here where I'm hosting a bunch of static sites for friends and > family with httpd (Let's Encrypt). Now, however, I've agreed to host a bunch > of Django (Unicorn) and Rails (Puma) apps as well, and I'm starting to think > maybe I've bitten off more than I can chew. > > Am I on the right path here? Would anybody mind giving me a nudge in the > right direction? > > ++--+-+--+ > Internet | pf | relayd | httpd | staticsite1.com:8000 | > | | (80/443) | | staticsite2.com:8000 | > | | | | staticsite3.com:8000 | > | | | | staticsite4.com:8000 | > | | | +--+ > | | | Unicorn | djangoapp1.com:7001 | > | | | | djangoapp2.com:7002 | > | | | +--+ > | | | Puma | railsapp1.com:6001 | > | | | | railsapp2.com:6002 | > ++--+-+--+ > > - > > /etc/pf.conf > > = > > pass in on $ext_if inet proto tcp from any to $ext_if port { 80, 443 } keep > state > > > > /etc/relayd.conf > > = > > my_ip="127.0.0.1" > relayd_port="80" > > table { $my_ip } > table { $my_ip } > table { $my_ip } > > http protocol "httpfilter" { > tcp { nodelay, sack, backlog 128 } > > return error > > match header set "X-Client-IP" value "$REMOTE_ADDR:$REMOTE_PORT" > match header set "X-Forwarded-For" value "$REMOTE_ADDR" > match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT" > } > > relay "reverseproxy" { > listen on $my_ip port $relayd_port > > protocol "httpfilter" > > forward to port 8000 > forward to port 7001 > forward to port 7002 > forward to port 6001 > forward to port 6002 > > } > > -- > > /etc/httpd.conf > > > > server "staticsite1.com" { > listen on * port 8000 > root "/htdocs/staticsite1.com" > [...] > } > > server "staticsite1.com" { > listen on * tls port 443 > root "/htdocs/staticsite1.com" > [...] > } > > [...] > > - > > Thanks, Joe
relayd + httpd + Django/Rails?
Hi, I got this VPS here where I'm hosting a bunch of static sites for friends and family with httpd (Let's Encrypt). Now, however, I've agreed to host a bunch of Django (Unicorn) and Rails (Puma) apps as well, and I'm starting to think maybe I've bitten off more than I can chew. Am I on the right path here? Would anybody mind giving me a nudge in the right direction? ++--+-+--+ Internet | pf | relayd | httpd | staticsite1.com:8000 | | | (80/443) | | staticsite2.com:8000 | | | | | staticsite3.com:8000 | | | | | staticsite4.com:8000 | | | | +--+ | | | Unicorn | djangoapp1.com:7001 | | | | | djangoapp2.com:7002 | | | | +--+ | | | Puma | railsapp1.com:6001 | | | | | railsapp2.com:6002 | ++--+-+--+ -- # /etc/pf.conf pass in on $ext_if inet proto tcp from any to $ext_if port { 80, 443 } keep state -- # /etc/relayd.conf my_ip="127.0.0.1" relayd_port="80" table { $my_ip } table { $my_ip } table { $my_ip } http protocol "httpfilter" { tcp { nodelay, sack, backlog 128 } return error match header set "X-Client-IP" value "$REMOTE_ADDR:$REMOTE_PORT" match header set "X-Forwarded-For" value "$REMOTE_ADDR" match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT" } relay "reverseproxy" { listen on $my_ip port $relayd_port protocol "httpfilter" forward to port 8000 forward to port 7001 forward to port 7002 forward to port 6001 forward to port 6002 } -- # /etc/httpd.conf server "staticsite1.com" { listen on * port 8000 root "/htdocs/staticsite1.com" [...] } server "staticsite1.com" { listen on * tls port 443 root "/htdocs/staticsite1.com" [...] } [...] -- Thanks, Joe
Re: MITM ?
> > What is your opinion ? > > could be a MITM from my router and a kernel 0day on the tcp/ip stack > > implementation ? > > could be MITMed pkg_add ? > > the encryption algorithm (AES_128_GCM) behind https is really secure ? > > Can some code be injected in an encrypted stream ? An internet connection might not suit your use case. Have you considered a self imposed air-gap?
amdgpu, Polaris and Firefox
I'm running the latest amd64 snapshot (kernel #619) on a system with a Radeon RX 550 (Polaris) GPU. glxgears and glxinfo show that OpenGL is working and Xorg.0.log shows no errors. When I try to enable OpenGL in Firefox by setting layers.acceleration.force-enable to true, I see the following errors on the terminal and https://get.webgl.org reports that WebGL is disabled or unavailable. libGL error: MESA-LOADER: failed to open radeonsi (search paths /usr/X11R6/lib/modules/dri) libGL error: failed to load driver: radeonsi libGL error: MESA-LOADER: failed to open swrast (search paths /usr/X11R6/lib/modules/dri) libGL error: failed to load driver: swrast libGL error: MESA-LOADER: failed to open radeonsi (search paths /usr/X11R6/lib/modules/dri) libGL error: failed to load driver: radeonsi libGL error: MESA-LOADER: failed to open swrast (search paths /usr/X11R6/lib/modules/dri) libGL error: failed to load driver: swrast And: Crash Annotation GraphicsCriticalError: |[G0][GFX1-]: [OPENGL] Failed to init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT (t=0.34852) [GFX1-]: [OPENGL] Failed to init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT Crash Annotation GraphicsCriticalError: |[G0][GFX1-]: [OPENGL] Failed to init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT (t=0.34852) |[G1][GFX1-]: [OPENGL] Failed to init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT (t=0.802629) [GFX1-]: [OPENGL] Failed to init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT Crash Annotation GraphicsCriticalError: |[G0][GFX1-]: [OPENGL] Failed to init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT (t=0.34852) |[G1][GFX1-]: [OPENGL] Failed to init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT (t=0.802629) |[G2][GFX1-]: [OPENGL] Failed to init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT (t=1.3604) [GFX1-]: [OPENGL] Failed to init compositor with reason: FEATURE_FAILURE_OPENGL_CREATE_CONTEXT Is this already known to be broken, or should I file a full bug report? Thanks, -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
Re: OpenBSD's extremely poor network/disk performance?
On Wed, Jan 08, 2020 at 05:57:37PM +0300, Hamd wrote: > Under less than 24 hours, after my post, the misc has received 2 or 3 brand > new questions/posts regarding slow*. Well, in the case of my issue, I am reasonably certain that this isn't an issue with LibreSSL. I raised it as an issue of simply not knowing how to get it to do what I need at the speeds it is clearly capable of, on i386. It works fine and at approximately OpenSSL speeds on amd64. > The problem is, well, obviously not me, personally. I beg to differ. Your repurposing my question for your own ends in an attempt to categorize it as an general OpenBSD performance issue is, in my opinion, full of **it. This is not helpful to those of us who are asking legitimate questions of those who are more familiar with these projects. I know I've made a dumb mistake of some sort and I was hoping someone would point it out. If you do not like the product, don't use it. Or submit a patch to fix it. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov
Re: LibreSSL performance issue
On Tue, Jan 07, 2020 at 11:06:38AM -0800, Jordan Geoghegan wrote: > Is there a specific reason you're running i386 instead of amd64? Yes, i386 generates substantially smaller images than amd64. In an environment where you are constrained to the existing available virtualization capacity and are tasked with making the most of that, there is no obvious reason why you would build infrastructure devices such as a DHCP server using amd64. We also have a supply of embedded Soekris systems which only run the i386. > And why are you testing this on FreeBSD? Wrong mailing list Probably not. LibreSSL is intended to be portable, and the LibreSSL web site points back to the OpenBSD mailing lists: https://www.libressl.org/mail.html "See https://www.openbsd.org/mail.html for more details on posting or subscribing." So now over at https://www.openbsd.org/mail.html ... I would think libre...@openbsd.org would seem the obvious choice of list. However, it is listed under "Developer lists These lists are for technical discussions of aspects of OpenBSD. They are NOT for beginners or average users, they are not for problem reporting (unless you are including a good fix) and they are not for installation problems. If you have any question about if a message should be posted to any of these lists, it probably should not. Use misc instead." So according to the guidelines on the website, my issue didn't fit libre...@openbsd.org, and there is an instruction to use misc instead. Besides, it came up as a reply to a message posted on misc. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov
Re: LibreSSL performance issue
On Tue, Jan 07, 2020 at 07:50:37PM +0100, Bodie wrote: > On 7.1.2020 17:26, Joe Greco wrote: > >On Tue, Jan 07, 2020 at 09:33:46AM -0600, Edgar Pettijohn wrote: > >>> In reality, when you dig down, often you find that there's another > >>> reason for the issue.?? I was recently trying to substitute libressl > >>> into an openssl environment.?? Performance tanked.?? Some checking > >>> showed the speed of "speed -evp aes-256-gcm" was way off.?? It looked > >>> to me like it was an issue with not using AES-NI.?? I'm not going to > >>> blame libressl for that, I just lacked the time to do a deep dive on > >>> it to figure out what was (hopefully!) configured wrong.?? Probably > >>> something with ia32cap or whatever the libressl equivalent is. > >>> > >>> ... JG > >> > >>I believe it has something to do with actually zeroing out memory > >>before freeing it. Which seems like a good thing to do for crypto > >>stuff. > > > >My apologies. I posted an insufficient description of the issue as it > >was intended as an argument refuting the OP. If we want to discuss my > >issue, that's fine and I welcome the input. I normally manage to > >resolve these things eventually but this stumped me a bit. > > [...] > >Now in the third run, calling the host system's OpenSSL but twiddling > >ia32cap, I get numbers that are very similar to the LibreSSL numbers > >showing a similar catastrophic performance reduction. My conclusion > >is that this is somehow an AES-NI detection issue. For whatever > >reason, > >FreeBSD's openssl gets it right by default. > > > >And the fourth run was "just to see." > > Just WOW > > So you start with blaming OpenBSD for poor performance and then as a > "prove" > you show tests of completely different OS on completely different > filesystem > on God knows which hypervisor and then throw in the mix amd64 vs i386? > > I think Phoronix will hire you ;-) I did no such thing. I used a problem I encountered as an example of how the original poster's implication isn't true. I did say "I'm not going to blame libressl". And if anything, if you read for comprehension, I defended OpenBSD. But now I kinda remember why I participate so rarely on these lists. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov
LibreSSL performance issue (was: Re: OpenBSD's extremely poor network/disk performance?)
date unspecified options:bn(64,32) rc4(8x,mmx) des(long) aes(partial) idea(int) blowfish(ptr) compiler: clang The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-gcm 170523.24k 458955.48k 727327.49k 860676.97k 911040.96k 911457.03k # OPENSSL_ia32cap="+0x202" openssl speed -evp aes-256-gcm Doing aes-256-gcm for 3s on 16 size blocks: 8813067 aes-256-gcm's in 2.99s Doing aes-256-gcm for 3s on 64 size blocks: 2483967 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 256 size blocks: 630526 aes-256-gcm's in 3.02s Doing aes-256-gcm for 3s on 1024 size blocks: 160181 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 8192 size blocks: 20112 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 16384 size blocks: 9988 aes-256-gcm's in 3.01s OpenSSL 1.1.1d-freebsd 10 Sep 2019 built on: reproducible build, date unspecified options:bn(64,32) rc4(4x,int) des(long) aes(partial) idea(int) blowfish(ptr) compiler: clang The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-gcm 47125.75k52853.66k53526.10k54533.10k54776.52k 54406.11k # OPENSSL_ia32cap="~0x202" libressl-3.0.2/apps/openssl/openssl spee -evp aes-256-gcm d WARNING: can't open config file: /usr/local/etc/ssl/openssl.cnf Doing aes-256-gcm for 3s on 16 size blocks: 9048488 aes-256-gcm's in 2.99s Doing aes-256-gcm for 3s on 64 size blocks: 2416620 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 256 size blocks: 583915 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 1024 size blocks: 151550 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 8192 size blocks: 19287 aes-256-gcm's in 3.00s LibreSSL 3.0.2 built on: date not available options:bn(64,32) rc4(ptr,int) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(idx) compiler: information not available The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256-gcm 48365.46k51406.29k49682.09k51580.05k52638.66k --End-FreeBSD-12.1R-i386 So the first run, with LibreSSL, the performance has fallen off catastrophically. The next run, calling the host system's shipped OpenSSL, the numbers return to reasonable, although they are somewhat slower than the amd64 runs. That's fine. Now in the third run, calling the host system's OpenSSL but twiddling ia32cap, I get numbers that are very similar to the LibreSSL numbers showing a similar catastrophic performance reduction. My conclusion is that this is somehow an AES-NI detection issue. For whatever reason, FreeBSD's openssl gets it right by default. And the fourth run was "just to see." After some more puttering around with it, that's where I got stuck, and I eventually set it aside as it wasn't a pressing issue. If anyone has any insight into this, feel free to tell me what I've done wrong. I'm sure this is simply a configuration thing. Thanks, ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov
Re: OpenBSD's extremely poor network/disk performance?
On Tue, Jan 07, 2020 at 02:47:02PM +, cho...@jtan.com wrote: > Hamd writes: > > It's 2020 and it's -still- sad to see OpenBSD -still- has the > > ... lists full of the uninteresting type of wine and that their > > twitterings -still- don't include any code. > > Yes. Yes it is. > > Can't say much for the performance of a suite of servers which have > all been taken down to handle the security threat du jour. Well, that's kind of ridiculous, that's not generally how threats are remediated in the real world. If you take a server down for 15 minutes to apply patches to Insecure- But-ZippyBSD, once a week, you get 99.85% uptime and presumably it is performing lots faster during that 99.85%, but admittedly performs at zero during the patch process. Redundancy can cover that in many cases. A different argument could be that if you require a particular level of performance, and you have to deploy more compute resources to get it, that increases capex and opex, and the end result is a greater level of e-waste down the road, and perhaps a greater amount of pollution if the power is generated from "bad" sources. In reality, when you dig down, often you find that there's another reason for the issue. I was recently trying to substitute libressl into an openssl environment. Performance tanked. Some checking showed the speed of "speed -evp aes-256-gcm" was way off. It looked to me like it was an issue with not using AES-NI. I'm not going to blame libressl for that, I just lacked the time to do a deep dive on it to figure out what was (hopefully!) configured wrong. Probably something with ia32cap or whatever the libressl equivalent is. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov
Re: heavy CPU consumption and laggy/stuttering video on thinkpad x230
This may come across as a strange question, but is the microphone disabled in the BIOS? The azalia driver has(had?) some issues with that before. Cheers, Joe
Re: no keyboard on (I)nstall
On Tue, Nov 12, 2019 at 10:12:13AM +0100, Emanuel Berg wrote: > CPU type AMD Athlon 64 X2 Dual Core Processor 3800+ > > Re: BIOS USB options... "USB Legacy Mode > Support" set to "Auto". > > No BIOS USB speed settings what I can see. > > -- > underground experts united > http://user.it.uu.se/~embe8573 > https://dataswamp.org/~incal > Does the USB keyboard have a USB hub on it, by any chance?
Re: Tools for writers
> Some writers swear on Scrivener. It's proprietary and Mac/Win only, though. Manuskript[1] looks promising as a foss alternative. Haven't attempted to build it on OpenBSD. None of the dependencies look to be a major problem. Cheers, Joe [1]: http://www.theologeek.ch/manuskript/
How to dock laptop more easily
I'd like to write a daemon to change machdep.lidaction and the xrandr output as an external monitor or power is attached/detached from my laptop. Is there a way to detect those events from a C program? Here is how I want the sleep state and output display to change based on whether power is connected, an external monitor is attached, and the laptop is open: PowerMon Open| SleepDisplay --+-- xxx | awakeboth xx| awakeexternal x x | awakelaptop x | asleep xx | awakeboth x| asleep x | awakelaptop | asleep -- Joe Nelson https://begriffs.com
Re: Alix 2d13 and OpenBSD 6.5 Problems
On 2019-10-01 22:46, Sean Kamath wrote: Hi. I’m hoping someone either has a cluebat or some helpful suggestions beyond “reinstall”. I had an alix 2d13 running OpenBSD 6.3. I finally got around to upgrading to 6.4 (via https://www.openbsd.org/faq/upgrade64.html), and that seemed to go just fine (I used the Upgrading Manually section, since I don’t have (easy) access to the console). I let that run for a day, just to make sure all was well, and then attempted an upgrade to 6.5 (via https://www.openbsd.org/faq/upgrade65.html), again using the “Upgrading Manually” section. This time, between smtpd and relinking the kernel, it appears my Alix board is quickly running out of memory. Within a few seconds the sr rate is in the 20K range. I stopped the ld for relinking, and killed SMTPD in order to finish the install (the makedev ALL, sysmerge, pkg_update -u bits), and that all ran fine. But about 15-20 minutes after a reboot, the box just goes off the network, and there’s not much I can do. I can download and reinstall 6.5, but was hoping to avoid that pain, but I just want to make sure 6.5 has no issues on the Alix boards. . . I cannot comment on the upgrade process, but I have had zero fatal issues running 6.5 on my alix2d13 boards. That said, memory has been getting tighter with more recent OpenBSD versions, and swap (as someone else suggested) should help. I love these reliable boards, but they are starting to show their age (at least relative to how I use them with OpenBSD). Thanks! I’d attach dmesg, but the box is dead again. . . If anyone wants to dive into what’s going on, just let me know what info you want to see. Sean
Re: arm on Tinker Board (rk3288) - currently broken?
> On Fri, Sep 27, 2019 at 08:01:53PM -0400, Joe Gidi wrote: >> Hello, >> >> I've seen a number of recent commits for the rk3288 SoC, so I dug out my >> Tinker Board and tried to install the latest snapshot (miniroot dated >> 27-Sep-2019 06:14). >> >> I followed the updated directions for this chip: >> >> For systems based on Rockchip RK3288 SoCs: >> >> dd if=/usr/local/share/u-boot/board/idbloader.img \ >> of=/dev/sdXc seek=64 >> dd if=/usr/local/share/u-boot/board/u-boot.img \ >> of=/dev/sdXc seek=16384 >> >> Unfortunately, when I try to boot, I get: >> >> rying to boot from BOOTROM >> Returning to boot ROM... >> >> U-Boot SPL 2019.07 (Sep 25 2019 - 20:12:08 -0600) >> Trying to boot from MMC1 >> spl: mmc init failed with error: -110 >> SPL: failed to boot from all boot devices >> ### ERROR ### Please RESET the board ### >> >> Is this currently known to be broken, or am I doing something wrong? > > tinker-rk3288 was broken in U-Boot 2019.07. I have just committed an > update to U-Boot 2019.10-rc4 which corrects this. Either build > u-boot-arm from ports or wait till updated packages appear. Following up to confirm that the updated U-Boot works. I was able to install and run the latest snap with no issues. Thanks! -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
arm on Tinker Board (rk3288) - currently broken?
Hello, I've seen a number of recent commits for the rk3288 SoC, so I dug out my Tinker Board and tried to install the latest snapshot (miniroot dated 27-Sep-2019 06:14). I followed the updated directions for this chip: For systems based on Rockchip RK3288 SoCs: dd if=/usr/local/share/u-boot/board/idbloader.img \ of=/dev/sdXc seek=64 dd if=/usr/local/share/u-boot/board/u-boot.img \ of=/dev/sdXc seek=16384 Unfortunately, when I try to boot, I get: rying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2019.07 (Sep 25 2019 - 20:12:08 -0600) Trying to boot from MMC1 spl: mmc init failed with error: -110 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### Is this currently known to be broken, or am I doing something wrong? Thanks, -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
unbound/dns issue (malformed packets?)
, the machines are otherwise configured exactly the same. The APU2 has been consistently maintained, and this behavior did start soon after I applied the libexpat update via syspatch. The ALIX machine, however, has not been patched (meaning it contains 6.5 as it was at release). I do not know much about the inner workings of DNS, and thinking that, perhaps, the packets contain XML and that the recent libexpat update is causing issues, I backed the update out of the APU2, but still get the same results. Similarly, swapping the (non-updated) ALIX in place of the APU2 results in the same behavior. Please forgive my verbosity, but I figured more info is probably better than less. My knowledge of DNS and other network services is limited -- I hope I have explained this in a way that can be understood. Thanks, Joe
Re: dhcrelay
Hi, You will find the answer in the second paragraph of the description for the dhcrelay(8) manpage. It's fantastic that we don't even need the internet to find the answer. Happy reading. Joe On 30/08/2019 8:21 AM, shadrock uhuru wrote: hiya thanks for the reply hi eveyone if i have a dhcp server in subnet A connected to interface em0 (lan) and subnet B connected to interface iwn0 (wireless zone) on the router with dhcrelay -i em0 running on the router should the wireless subnet be able?? to get its dhcp address from the dhcp server on the lan ? No, you would need to run dhcrelay -i iwn0 to do that. finally got that sorted, but led me to another question i have two dhcp servers on samba domain controllers, can a second server-ip address be added like this to dhcrelay dhcrelay -i iwn0 i haven't seen any examples like this on the net shadrock
Re: SAD ( pkg_add does linux like stuff ie: not working, no explanation )
> Maybe obvious ? if so why no message from the software ? > > [0]-[web]-[/var/www/logs] > # pkg_add php_curl > quirks-3.124 signed on 2019-04-15T12:10:16Z > Can't find php_curl > [0]-[web]-[/var/www/logs] > # cat /etc/installurl > http://cdn.openbsd.org/pub/OpenBSD > > But > > [0]-[web]-[/var/www/logs] > # curl --head > https://cdn.openbsd.org/pub/OpenBSD/6.5/packages/amd64/php-curl-7.2.17.tgz > HTTP/2 200 > server: nginx > content-type: application/octet-stream > last-modified: Mon, 15 Apr 2019 12:09:10 GMT > etag: "5cb47466-8e35" > backend-name: 5GnZ0LBU5CzDw9NCjFbkjI--F_ftp_hostserver_de > accept-ranges: bytes > date: Wed, 28 Aug 2019 14:01:52 GMT > via: 1.1 varnish > age: 0 > x-served-by: cache-cdg20753-CDG > x-cache: MISS > x-cache-hits: 0 > x-timer: S1567000912.203130,VS0,VE54 > content-length: 36405 > [0]-[web]-[/var/www/logs] > # date > Wed Aug 28 04:07:24 CEST 2019 > > LIKE WHY PLEASE ? Maybe because underscores (_) are not the same as dashes (-)? -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
Re: openrsync out of memory
By the looks of it, openrsync does attempt to map the entire file, from usr.bin/rsync/uploader.c: mapsz = st.st_size; map = mmap(NULL, mapsz, PROT_READ, MAP_SHARED, *fileinfd, 0); The likely reason for your out of memory error is the default datasize in login.conf. IIRC on some arches it's set to 768MB by default, which would allow your 300MB file to transfer, but would cause mmap to fail upon attempting to map the 1.6GB one. Increasing the default limits in /etc/login.conf should fix the problem. Note that rsync (not openrsync), doesn't use mmap for other reasons, from rsync-3.1.3/fileio.c: /* This provides functionality somewhat similar to mmap() but using read(). * It gives sliding window access to a file. mmap() is not used because of * the possibility of another program (such as a mailer) truncating the * file thus giving us a SIGBUS. */ Cheers, Joe
Re: Multiple video cards in X?
Hello, I have multiple video cards (AMD Radeon) cards working with OpenBSD. I have 2 monitors connected to each card (HDMI and DVI ports). The issues are that I can use only fvwm and I cannot move x windows across the video cards. I can move x windows across monitors connected to the same video card though. I tried to hack around the Xenocara codebase to figure out if I can fix it. During my adventures, I realized that though Xenocara can be modified to support this, the issue is in the radeon driver (radeondrm, I think). At that point, I gave up as I did not have the bandwidth to figure out how radeondrm works. It took me quite a lot of time to figure out the correct configuration. I was hoping that I could get cwm to work. But, I could not. Only fvwm works. I did not bother to dig through why. joe:10114$ cat /etc/X11/xorg.conf # get the xorg.conf.firstcard and xorg.conf.secondcard to work # startx # uses xorg.conf # cd /etc/X11; start -- :1 -config xorg.conf.secondcard # to get the second card working # once both of them work, below is bringing them together to show all monitors at the same time # leave out the monitor sections as the X fills up the holes Section "ServerLayout" Identifier "Default Layout" Screen 0 "Screen 0" Screen 1 "Screen 1" RightOf "Screen 0" EndSection Section "Screen" Identifier "Screen 0" Device "Card 0" EndSection Section "Device" Identifier "Card 0" Driver "radeon" BusID "PCI:1:0:0" #Option "Monitor-HDMI-0" "HG281D" Option "Monitor-DVI-0" "AL2223W" EndSection Section "Monitor" Identifier "AL2223W" Option "LeftOf" "HDMI-0" EndSection Section "Screen" Identifier "Screen 1" Device "Card 1" EndSection Section "Device" Identifier "Card 1" Driver "radeon" BusID "PCI:11:0:0" EndSection joe:10131$ tail -5 /home/j/.xsession # cwm cannot spawn multiple cards # exec /usr/X11R6/bin/cwm exec fvwm Hope it helps. On Thu, Jun 27, 2019 at 12:38 PM Nick Holland wrote: > > Hiya. > > Before I spend a lot of time on what might be impossible, is it likely I > could succeed at getting multiple multi-head video cards working on > OpenBSD (amd64, radeon cards)? > > I've got this in the machine: > OpenBSD 6.5-current (GENERIC.MP) #2: Sun Jun 2 00:29:17 MDT 2019 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > ppb2 at pci0 dev 3 function 0 "Intel X58 PCIE" rev 0x22: msi > pci3 at ppb2 bus 3 > radeondrm0 at pci3 dev 0 function 0 "ATI Radeon HD 5450" rev 0x00 > drm0 at radeondrm0 > radeondrm0: msi > ppb3 at pci0 dev 7 function 0 "Intel X58 PCIE" rev 0x22: msi > pci4 at ppb3 bus 4 > radeondrm1 at pci4 dev 0 function 0 "ATI Radeon HD 3450" rev 0x00 > drm1 at radeondrm1 > radeondrm1: msi > ... > > so I got a pair of cards recognized. Two monitors on one card Just Work > with X with no xorg.conf file. xrandr sees the config and seems to > work, driving the monitors at full resolution. > > But the other card is ... idle. > > Is it possible to use my other monitors in X on OpenBSD? Any Broad > General Tips in doing so? Man pages to read? Authoritative tips, > including "Don't be an idiot, it's easy" to "it's not possible"? > > To save 45k per copy of this message, links to dmesg and xorg log: > > http://nickh.org/Xorg.0.log.txt > http://nickh.org/dmesg.txt > > Nick. >
Re: Haskell compilation issues
Matthias Kilian wrote: > I've a really smart solution for the problem: I'll never ever even try > to give some helpful answer to any of the mails on misc@ Sorry, my message must have sounded snarky. I didn't intend it that way. Honestly just wanted to help you with your email setup. It can be complicated, and I've only recently learned about some of this stuff myself. Maybe I should have replied off-list originally, but thought the mail header tip might be useful for other people as well.
Re: Haskell compilation issues
Matthias Kilian wrote: > ps: please note that I'm not subscribed to misc@ with my 'real' > mail account, only with a crappy gmail account I'm only reading on > my tablet (from which I forwarded your mail to my real address). So > better cc' me if you've any other questions ;-) FYI, the way you replied to the original message broke the reply chain in my mail reader (Mutt). You should include an "In-Reply-To" message header that references the Message-ID of the mail to which you are replying. I know it might be a little tricky from your tablet setup, but wanted to bring it to your attention if you weren't aware. In your particular case it would have been: In-Reply-To:
Re: Haskell compilation issues
Omar Polo wrote: > What I think it's required to compile and run haskell program is to > wxallow the partition. If you're using the standard layout the /tmp > and /home should be wxallowed. Yep, GHC creates binaries with W^X violations. The GHC developers are working on this problem in [0], but for now Haskell binaries have to be run from a filesystem mounted as wxallowed. 0: https://gitlab.haskell.org/ghc/ghc/issues/14069
_XSERVTransSocketUNIXAccept: accept() failed
Hello, These messages are filling up the Xorg.0.log and xenodm.log to gigabytes and does not allow additional xterm windows to open. I see these messages in /var/log/Xorg.0.log joe:10424$ tail Xorg.0.log [2616181.044] _XSERVTransSocketUNIXAccept: accept() failed [2616181.044] _XSERVTransSocketUNIXAccept: accept() failed [2616181.044] _XSERVTransSocketUNIXAccept: accept() failed [2616181.044] _XSERVTransSocketUNIXAccept: accept() failed [2616181.044] _XSERVTransSocketUNIXAccept: accept() failed [2616181.044] _XSERVTransSocketUNIXAccept: accept() failed [2616181.044] _XSERVTransSocketUNIXAccept: accept() failed [2616181.044] _XSERVTransSocketUNIXAccept: accept() failed [2616181.044] _XSERVTransSocketUNIXAccept: accept() failed [2616181.045] _XSERVTransSocketUNIXAccept: accept() failed joe:10425$ tail /var/log/xenodm.log _XSERVTransSocketUNIXAccept: accept() failed _XSERVTransSocketUNIXAccept: accept() failed _XSERVTransSocketUNIXAccept: accept() failed _XSERVTransSocketUNIXAccept: accept() failed _XSERVTransSocketUNIXAccept: accept() failed _XSERVTransSocketUNIXAccept: accept() failed _XSERVTransSocketUNIXAccept: accept() failed _XSERVTransSocketUNIXAccept: accept() failed _XSERVTransSocketUNIXAccept: accept() failed _XSERVTransSocketUNIXAccept: accept() failed Thanks to #openbsd's epony and oldlaptop, the resolution is to: 1. increase daemon openfiles-max to 2048 and openfiles-cur to 1024 in /etc/login.conf 2. cap_mkdb /etc/login.conf 3. re-login. Thanks
Re: Criteria for errata
> > > That's how I understood the bug too, but when I enabled a debug build of > > > xenocara and examined the core dump after a crash, I had the same > > > "VGAarbiterSpriteMoveCursor" recursive-stack backtrace as in that bug > > > report. > > > > I dont know much about xenocara, but i think that including dmesg and > > maybe /var/log/Xorg.0.log output in your mail can't hurt. > > > > I already have a bug report sent to bugs@ > > https://marc.info/?l=openbsd-bugs=155716824903439=2 > A few weeks ago, I was told that this fix was added to -current. I cannot find the email now though.
Patch for X crash on 6.4 and 6.5
Hello, I had this same issue with 6.4 and 6.5. Applying this patch has fixed the issue. I am using 2 radeon gpu's. https://patchwork.freedesktop.org/series/28284/ This is the gdb backtrace of the crashed core file. joe:10201$ d gdb /usr/X11R6/bin/X Xorg.core GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-unknown-openbsd6.5"... Core was generated by `Xorg'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libpthread.so.26.1...done. Loaded symbols for /usr/lib/libpthread.so.26.1 Loaded symbols for /usr/X11R6/bin/X Symbols already loaded for /usr/lib/libpthread.so.26.1 Reading symbols from /usr/X11R6/lib/libpciaccess.so.2.0...done. Loaded symbols for /usr/X11R6/lib/libpciaccess.so.2.0 Reading symbols from /usr/X11R6/lib/libdrm.so.7.6...done. Loaded symbols for /usr/X11R6/lib/libdrm.so.7.6 Reading symbols from /usr/X11R6/lib/libpixman-1.so.36.0...done. Loaded symbols for /usr/X11R6/lib/libpixman-1.so.36.0 Reading symbols from /usr/X11R6/lib/libXfont2.so.1.0...done. Loaded symbols for /usr/X11R6/lib/libXfont2.so.1.0 Reading symbols from /usr/X11R6/lib/libfontenc.so.4.0...done. Loaded symbols for /usr/X11R6/lib/libfontenc.so.4.0 Reading symbols from /usr/X11R6/lib/libfreetype.so.29.0...done. Loaded symbols for /usr/X11R6/lib/libfreetype.so.29.0 Reading symbols from /usr/lib/libz.so.5.0...done. Loaded symbols for /usr/lib/libz.so.5.0 Reading symbols from /usr/X11R6/lib/libXau.so.10.0...done. Loaded symbols for /usr/X11R6/lib/libXau.so.10.0 Reading symbols from /usr/X11R6/lib/libxshmfence.so.0.0...done. Loaded symbols for /usr/X11R6/lib/libxshmfence.so.0.0 Reading symbols from /usr/X11R6/lib/libXdmcp.so.11.0...done. Loaded symbols for /usr/X11R6/lib/libXdmcp.so.11.0 Reading symbols from /usr/lib/libkvm.so.17.0...done. Loaded symbols for /usr/lib/libkvm.so.17.0 Reading symbols from /usr/lib/libm.so.10.1...done. Loaded symbols for /usr/lib/libm.so.10.1 Reading symbols from /usr/lib/libc.so.95.0...done. Loaded symbols for /usr/lib/libc.so.95.0 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so Reading symbols from /usr/X11R6/lib/modules/extensions/libglx.so...done. Loaded symbols for /usr/X11R6/lib/modules/extensions/libglx.so Reading symbols from /usr/X11R6/lib/libGL.so.17.1...done. Loaded symbols for /usr/X11R6/lib/libGL.so.17.1 Reading symbols from /usr/lib/libexpat.so.12.0...done. Loaded symbols for /usr/lib/libexpat.so.12.0 Reading symbols from /usr/X11R6/lib/libxcb-dri3.so.0.1...done. Loaded symbols for /usr/X11R6/lib/libxcb-dri3.so.0.1 Reading symbols from /usr/X11R6/lib/libxcb-xfixes.so.1.2...done. Loaded symbols for /usr/X11R6/lib/libxcb-xfixes.so.1.2 Reading symbols from /usr/X11R6/lib/libxcb-present.so.0.1...done. Loaded symbols for /usr/X11R6/lib/libxcb-present.so.0.1 Reading symbols from /usr/X11R6/lib/libxcb-sync.so.1.2...done. Loaded symbols for /usr/X11R6/lib/libxcb-sync.so.1.2 Reading symbols from /usr/X11R6/lib/libglapi.so.0.2...done. Loaded symbols for /usr/X11R6/lib/libglapi.so.0.2 Reading symbols from /usr/X11R6/lib/libXdamage.so.4.0...done. Loaded symbols for /usr/X11R6/lib/libXdamage.so.4.0 Reading symbols from /usr/X11R6/lib/libXfixes.so.6.0...done. Loaded symbols for /usr/X11R6/lib/libXfixes.so.6.0 Reading symbols from /usr/X11R6/lib/libX11-xcb.so.2.0...done. Loaded symbols for /usr/X11R6/lib/libX11-xcb.so.2.0 Reading symbols from /usr/X11R6/lib/libxcb-glx.so.1.1...done. Loaded symbols for /usr/X11R6/lib/libxcb-glx.so.1.1 Reading symbols from /usr/X11R6/lib/libxcb-dri2.so.1.1...done. Loaded symbols for /usr/X11R6/lib/libxcb-dri2.so.1.1 Reading symbols from /usr/X11R6/lib/libXxf86vm.so.6.0...done. Loaded symbols for /usr/X11R6/lib/libXxf86vm.so.6.0 Reading symbols from /usr/X11R6/lib/libXext.so.13.0...done. Loaded symbols for /usr/X11R6/lib/libXext.so.13.0 Reading symbols from /usr/X11R6/lib/libX11.so.16.1...done. Loaded symbols for /usr/X11R6/lib/libX11.so.16.1 Reading symbols from /usr/X11R6/lib/libxcb.so.4.0...done. Loaded symbols for /usr/X11R6/lib/libxcb.so.4.0 Reading symbols from /usr/X11R6/lib/modules/drivers/radeon_drv.so...done. Loaded symbols for /usr/X11R6/lib/modules/drivers/radeon_drv.so Reading symbols from /usr/X11R6/lib/libdrm_radeon.so.4.0...done. Loaded symbols for /usr/X11R6/lib/libdrm_radeon.so.4.0 Reading symbols from /usr/X11R6/lib/libgbm.so.0.3...done. Loaded symbols for /usr/X11R6/lib/libgbm.so.0.3 Reading symbols from /usr/X11R6/lib/modules/libfb.so...done. Loaded symbols for /usr/X11R6/lib/modules/libfb.so Reading symbols from /usr/X11R6/lib/modules/libexa.so...done. Loaded symbols for /usr/X11R6/lib/modules/libexa.so Reading symbols from /usr/X11
Re: clocksource tsc sometimes not available within debian vm on OpenBSD 6.4
I have the same issue and have been using this driver. It sets the correct time every 5 seconds. For this purpose, this solution is a hack, but, I could not figure out a better solution. https://github.com/voutilad/virtio_vmmci/issues/1 Also, I noticed that vm clock would be very slow. It loses 28 minutes for every 30 minutes. Another thing, watch out regarding tsc=unreliable kernel command line option, the vm is getting unresponsive with it after an hour or so.
Re: HP OfficeJet 5610 Scanner
> I have this exact model. Were you able to get printing to work? I do not use it for printing anymore. So, never tried printing with it.
Re: HP OfficeJet 5610 Scanner
It works fine after installing hplip. For the next person trying this, these commands got it working: doas pkg_add sane-backends hplip dbus doas rcctl enable messagebus doas rcctl start messagebus scanimage should work fine now. Thanks
Re: _XSERVTransSocketUNIXAccept: accept() failed
> What were you trying to do when you got these messages? This happens when I have a bunch of X apps (with windows) open and I try open another xterm. It appears that there is some limit to the number of X windows that can be opened. When I try to open another one after that limit, I get these messages. I checked 'man login.conf' but nothing seemed relevant. I am not sure if any sysctl values might be responsible for this behaviour though. Thanks
_XSERVTransSocketUNIXAccept: accept() failed
Hello, I see these messages in /var/log/Xorg.0.log joe:10424$ tail Xorg.0.log [2616181.044] _XSERVTransSocketUNIXAccept: accept() failed [2616181.044] _XSERVTransSocketUNIXAccept: accept() failed [2616181.044] _XSERVTransSocketUNIXAccept: accept() failed [2616181.044] _XSERVTransSocketUNIXAccept: accept() failed [2616181.044] _XSERVTransSocketUNIXAccept: accept() failed [2616181.044] _XSERVTransSocketUNIXAccept: accept() failed [2616181.044] _XSERVTransSocketUNIXAccept: accept() failed [2616181.044] _XSERVTransSocketUNIXAccept: accept() failed [2616181.044] _XSERVTransSocketUNIXAccept: accept() failed [2616181.045] _XSERVTransSocketUNIXAccept: accept() failed joe:10425$ tail /var/log/xenodm.log _XSERVTransSocketUNIXAccept: accept() failed _XSERVTransSocketUNIXAccept: accept() failed _XSERVTransSocketUNIXAccept: accept() failed _XSERVTransSocketUNIXAccept: accept() failed _XSERVTransSocketUNIXAccept: accept() failed _XSERVTransSocketUNIXAccept: accept() failed _XSERVTransSocketUNIXAccept: accept() failed _XSERVTransSocketUNIXAccept: accept() failed _XSERVTransSocketUNIXAccept: accept() failed _XSERVTransSocketUNIXAccept: accept() failed Any suggestions on how to figure out why this is happening. Thanks
Re: HP OfficeJet 5610 Scanner
This is from dmesg ulpt0 at uhub5 port 1 configuration 1 interface 1 "HP Officejet 5600 series" rev 2.00/1.00 addr 2 ulpt0: using bi-directional mode ugen1 at uhub5 port 1 configuration 1 "HP Officejet 5600 series" rev 2.00/1.00 addr 2
HP OfficeJet 5610 Scanner
Hello, I have an HP OfficeJet 5610 All-In-One that worked fine with scanimage on linux. On Openbsd, sane-find-scanner recognises the device but scanimage --list-devices cannot find it. Just want to check if anyone has it working on OpenBSD? joe:10362$ d sane-find-scanner # sane-find-scanner will now attempt to detect your scanner. If the # result is different from what you expected, first make sure your # scanner is powered up and properly connected to your computer. # No SCSI scanners found. If you expected something different, make sure that # you have loaded a kernel SCSI driver for your SCSI adapter. could not fetch string descriptor: Input/output error could not fetch string descriptor: Input/output error found USB scanner (vendor=0x03f0 [HP], product=0x4f11 [Officejet 5600 series]) at libusb:005:002 found USB scanner (vendor=0x1b1c [Corsair Components, Inc.], product=0x0c09 [H100i v2]) at libusb:006:003 # Your USB scanner was (probably) detected. It may or may not be supported by # SANE. Try scanimage -L and read the backend's manpage. # Not checking for parallel port scanners. # Most Scanners connected to the parallel port or other proprietary ports # can't be detected by this program. joe:10370$ d scanimage --list-devices [bjnp] create_broadcast_socket: ERROR - bind socket to local address failed - Can't assign requested address [bjnp] create_broadcast_socket: ERROR - bind socket to local address failed - Can't assign requested address [bjnp] create_broadcast_socket: ERROR - bind socket to local address failed - Can't assign requested address [bjnp] create_broadcast_socket: ERROR - bind socket to local address failed - Can't assign requested address [bjnp] create_broadcast_socket: ERROR - bind socket to local address failed - Can't assign requested address No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). Thanks Joe
Re: drm bug on Dell Inspiron 3721 (6.4release and 6.4 current)
I had a similar issue when attempting to boot on an 2011 iMac with a radeon card. I did track down the location of the bug, but I didn't get around to reporting it. As far as I can tell the problem is this line (243, in -current) in dev/pci/drm/radeon/radeon_bios.c, in the function radeon_read_bios: #else bios = (u8 *)ISA_HOLE_VADDR(0xc); #endif It makes the assumption that the system firmware has mapped the graphics card ROM at 0xC. This works fine on most computers if legacy BIOS compatiblity is enabled, but breaks on (U)EFI systems which have it disabled or unavailable. Apple hardware for instance, if booted in EFI mode, don't map anything to 0xC and make no attempt to have legacy BIOS compatibility unless specifically told to boot a legacy bootsector. I worked around it on that iMac by doing an MBR installation rather than EFI/GPT. On other hardware, I'd recommend going into your BIOS settings and ensuring that Legacy BIOS/CSM compatibility is enabled, and it isn't set to UEFI-only. A robust fix would have the radeon_get_bios map the ROM into memory itself instead of relying on the firmware to do it. This is how the linux code (line 208) works. Cheers, Joe
Xorg crash every few days
in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34904 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34905 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34906 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34907 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34908 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34909 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34910 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34911 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34912 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34913 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34914 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34915 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X Segmentation fault (core dumped) I am attaching my dmesg. Please let me know if I can provide any more information. Thanks Joe OpenBSD 6.4 (GENERIC.MP) #1: Mon Nov 26 10:18:14 CET 2018 r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 21417054208 (20424MB) avail mem = 20758691840 (19797MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb450 (77 entries) bios0: vendor American Megatrends Inc. version "Ua9" date 03/06/2013 bios0: Gigabyte Technology Co., Ltd. Z68AP-D3 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT SSDT DMAR acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(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) Core(TM) i7-2600 CPU @ 3.40GHz, 3410.55 MHz, 06-2a-07 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3410.02 MHz, 06-2a-07 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3410.02 MHz, 06-2a-07 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3410.02 MHz, 06-2a-07 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3410.02 MHz, 06-2a-07 cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 1, core 0, package 0 cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3410.02 MHz, 06-2a-07 cpu5: 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,
Re: alpine linux under vm? freezes
> so is there anything I could do to be able to use the console? Try setting a lower baud rate in Alpine’s /etc/inittab. (and in the linux kernel command line) That’s how I worked around the same issue. Regards, Joe
Re: Error adding tunnel to mgre interface
On 1/08/2018 7:52 p.m., j...@snoopy.net.nz wrote: Hi, I am trying to add a tunnel to an mgre interface. I can't get past the following error. $doas ifconfig mgre0 destroy $doas ifconfig mgre0 create $doas ifconfig mgre0 tunnel 192.0.2.1 192.0.2.1 ifconfig: SIOCSLIFPHYADDR: Invalid argument $ $ifconfig mgre mgre0: flags=8800 mtu 1476 index 9 priority 0 llprio 3 encap: vnetid none groups: mgre tunnel: (unset) ttl 64 nodf $ This is on a default install with patches up to and including 014. OpenBSD 6.3 GENERIC.MP#7 amd64 If anyone has had success setting up an mgre interface then I would appreciate a little advice. Regards Joe I found the answer in an openbsd-cvs archive. Ref. https://marc.info/?l=openbsd-cvs=151977078027087=2 Example command. >$ doas ifconfig mgre0 tunneladdr 192.0.2.1 >$ ifconfig mgre mgre0: flags=8800 mtu 1476 index 24 priority 0 llprio 3 encap: vnetid none groups: mgre tunnel: inet 192.0.2.1 ttl 64 nodf Regards Joe COok --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Error adding tunnel to mgre interface
Hi, I am trying to add a tunnel to an mgre interface. I can't get past the following error. $doas ifconfig mgre0 destroy $doas ifconfig mgre0 create $doas ifconfig mgre0 tunnel 192.0.2.1 192.0.2.1 ifconfig: SIOCSLIFPHYADDR: Invalid argument $ $ifconfig mgre mgre0: flags=8800 mtu 1476 index 9 priority 0 llprio 3 encap: vnetid none groups: mgre tunnel: (unset) ttl 64 nodf $ This is on a default install with patches up to and including 014. OpenBSD 6.3 GENERIC.MP#7 amd64 If anyone has had success setting up an mgre interface then I would appreciate a little advice. Regards Joe
pf.conf "reply-to" routing parameter seemingly not working?
Hello! I have a trunk0 interface on a router (#1) that is used for a singular purpose -- to pass (IPsec protected) traffic for an IPIP tunnel (gif0) to another router (#2). I have configured PF rules on router #1 that prevent any other type of traffic from passing on trunk0. There are several routing table entries that forward to router #2 on gif0. My objective is to configure an additional pass rule that would allow SSH traffic destined for router #1 to pass in and out on trunk0. The problem is that the aforementioned routes on gif0 cause packets sent in reply to incoming SSH traffic to pass out on gif0 (after passing in on trunk0). This ends up getting blocked by PF on router #1 because the state-policy is set to if-bound (which is how I want it). I am trying to use reply-to to enforce symmetric routing, but it isn't working. As you will see below, my "reply-to" rule is matched, but the reply is _still_ routed to gif0: # tcpdump -nevvpi pflog0 tcp port 22 tcpdump: WARNING: snaplen raised from 116 to 224 tcpdump: listening on pflog0, link-type PFLOG 01:27:46.503040 rule 5/(match) [uid 0, pid 16018] pass in on trunk0: [uid 4294967295, pid 10] [SSH CLIENT IP].57427 > [TRUNK0 IP].22: S [tcp sum ok] 1707770457:1707770457(0) win 64240 (DF) (ttl 127, id 24244, len 52) 01:27:46.503069 rule 4/(match) [uid 0, pid 16018] block out on gif1: [uid 4294967295, pid 10] [TRUNK0 IP].22 > [SSH CLIENT IP].57427: S [tcp sum ok] 4100262020:4100262020(0) ack 1707770458 win 16384 (DF) (ttl 64, id 43497, len 52, bad ip cksum 0! -> d71b) ^C 2 packets received by filter 0 packets dropped by kernel # pfctl -sr | grep @5 @5 pass in log quick on trunk0 inet proto tcp from any to [TRUNK0 IP] port = 22 flags S/SA keep state (if-bound) reply-to @trunk0 Router #1 is running OpenBSD 6.2. Anyone have any idea why this isn't working the way I want it to? Joe
Re: ICMPv6 Neighbor Advertisement PF Weirdness
I solved the problem described in my last email. The problem was that we copy pasted the IPv6 address for each vlan interface, and then changed part of the address for each interface, but failed to change the prefix length to 64. This meant that each vlan interface had a different address, but shared the same subnet with other interfaces. Obviously this resulted in an "unusual" route table -- but it is unclear to us why the previously described PF problem manifested in the way it did -- especially given that the ICMPv6 packet used link-local addresses, and the pass rule did not filter on interface. Seems like it is possibly a bug. Joe On Mon, Apr 30, 2018 at 12:31 PM, Joe Crivello <josephcrive...@gmail.com> wrote: > Hello -- > > While configuring a new firewall, I noticed that pflog0 was showing that > some ICMPv6 neighbor advertisement packets were being blocked in on vlan51, > which is a sub-interface of vmx1 (a vmxnet3 interface using VGT). I added a > PF rule allowing this traffic to pass. However, even after adding the rule > and flushing all state, the traffic was still being reported as blocked in > by pflog0. Thinking that there might be something else wrong with the rule > set, I made the pass rule "quick" and inserted it as the first pass rule in > the set. This still didn't work. > > See below for (1) the first two rules of the rule set (they are the only > ones that matter in this example), (2) a tcpdump that was run after the > rule set was applied and states were flushed, showing the blocked traffic, > and (3) the interface configurations in question. > > # pfctl -sr > FILTER RULES: > block drop log all label "Block all" > pass in quick on any inet6 proto ipv6-icmp all icmp6-type neighbradv > > # tcpdump -netvvi pflog0 "icmp6 && ip6[40] == 136" > tcpdump: WARNING: snaplen raised from 116 to 160 > tcpdump: listening on pflog0, link-type PFLOG > rule 1/(match) [uid 0, pid 91607] block in on vlan51: > fe80::1905:23c0:fe7a:dcfe > ff02::1: [|icmp6] (len 32, hlim 255) > ^C > 7 packets received by filter > 0 packets dropped by kernel > > # ifconfig vmx1 > vmx1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > lladdr 00:0c:29:50:66:d1 > index 2 priority 0 llprio 3 > media: Ethernet autoselect (10GbaseT) > status: active > inet6 fe80::20c:29ff:fe50:66d1%vmx1 prefixlen 64 scopeid 0x2 > > # ifconfig vlan51 > vlan51: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > lladdr 00:0c:29:50:66:d1 > description: > index 7 priority 0 llprio 3 > encap: vnetid 51 parent vmx1 > groups: vlan inetusr resolverusr > media: Ethernet autoselect (10GbaseT) > status: active > inet6 fe80::20c:29ff:fe50:66d1%vlan51 prefixlen 64 scopeid 0x7 > inet 10.84.51.1 netmask 0xff00 broadcast 10.84.51.255 > inet6 ::1 prefixlen 56 > > The firewall is a VMware ESXi 6.5 virtual machine running > SecurityRouter.org 6.2-lyra -- which is a distribution based on OpenBSD 6.2. > > Thinking that this might be a problem with the vmx(4) driver, we changed > the network interface to emulated E1000e (em(4)), no change. Also tried > adding "allow-opts" to the pass rule, no change. > > I understand this list isn't meant to support SecurityRouter.org's > distribution of OpenBSD... but does anyone see something obviously wrong > with my rule set or my expectations of how it should behave? Are there > known problems with using VGT on VMware ESXi with vmx(4) and em(4) drivers? > I reviewed the 6.2 errata and didn't see anything pertinent. > > Joe > >
ICMPv6 Neighbor Advertisement PF Weirdness
Hello -- While configuring a new firewall, I noticed that pflog0 was showing that some ICMPv6 neighbor advertisement packets were being blocked in on vlan51, which is a sub-interface of vmx1 (a vmxnet3 interface using VGT). I added a PF rule allowing this traffic to pass. However, even after adding the rule and flushing all state, the traffic was still being reported as blocked in by pflog0. Thinking that there might be something else wrong with the rule set, I made the pass rule "quick" and inserted it as the first pass rule in the set. This still didn't work. See below for (1) the first two rules of the rule set (they are the only ones that matter in this example), (2) a tcpdump that was run after the rule set was applied and states were flushed, showing the blocked traffic, and (3) the interface configurations in question. # pfctl -sr FILTER RULES: block drop log all label "Block all" pass in quick on any inet6 proto ipv6-icmp all icmp6-type neighbradv # tcpdump -netvvi pflog0 "icmp6 && ip6[40] == 136" tcpdump: WARNING: snaplen raised from 116 to 160 tcpdump: listening on pflog0, link-type PFLOG rule 1/(match) [uid 0, pid 91607] block in on vlan51: fe80::1905:23c0:fe7a:dcfe > ff02::1: [|icmp6] (len 32, hlim 255) ^C 7 packets received by filter 0 packets dropped by kernel # ifconfig vmx1 vmx1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr 00:0c:29:50:66:d1 index 2 priority 0 llprio 3 media: Ethernet autoselect (10GbaseT) status: active inet6 fe80::20c:29ff:fe50:66d1%vmx1 prefixlen 64 scopeid 0x2 # ifconfig vlan51 vlan51: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr 00:0c:29:50:66:d1 description: index 7 priority 0 llprio 3 encap: vnetid 51 parent vmx1 groups: vlan inetusr resolverusr media: Ethernet autoselect (10GbaseT) status: active inet6 fe80::20c:29ff:fe50:66d1%vlan51 prefixlen 64 scopeid 0x7 inet 10.84.51.1 netmask 0xff00 broadcast 10.84.51.255 inet6 ::1 prefixlen 56 The firewall is a VMware ESXi 6.5 virtual machine running SecurityRouter.org 6.2-lyra -- which is a distribution based on OpenBSD 6.2. Thinking that this might be a problem with the vmx(4) driver, we changed the network interface to emulated E1000e (em(4)), no change. Also tried adding "allow-opts" to the pass rule, no change. I understand this list isn't meant to support SecurityRouter.org's distribution of OpenBSD... but does anyone see something obviously wrong with my rule set or my expectations of how it should behave? Are there known problems with using VGT on VMware ESXi with vmx(4) and em(4) drivers? I reviewed the 6.2 errata and didn't see anything pertinent. Joe
Re: Plans to port the amdgpu(4) driver? (=to support Radeons made 2014/2015 and after.) Hardware/other donations needed?
> On Wed, Apr 25, 2018 at 10:49:53AM -0400, Joe Gidi wrote: >> >> > On Wed, Apr 25, 2018 at 09:08:12PM +1000, Jonathan Gray wrote: >> >> drivers/gpu/drm/amd in linux has over 1.5 million lines of code. >> Which >> >> is multiple times larger than the complete OpenBSD kernel source... >> >> Thanks for this update! >> >> Just to clarify, before I spend a bunch of money on new hardware, should >> I >> be able to use a Radeon R7 250 to drive a 4k monitor via DisplayPort >> with >> this updated driver? >> >> Thanks again, > > It appears that 'R7 250' can mean either a cape verde or oland radeon > depending on the model. Both are GCN parts. > > 4k 30Hz should be possible with HDMI, 4k 60Hz on HDMI requires HDMI 2.0 > Both claim support for displayport 1.2 which should be able to do > 4k 60Hz. HDMI 2.0 seems to only be on later hardware with DCE >= 11 > carrizo (not carrizo-l which is mullins), polaris etc. > > With the low end radeons displayport is sometimes only available on > oem models of cards sold as options for systems marketed as business > desktops or workstations. > > And as mentioned earlier for acceleration you'll currently have to build > a different version of Mesa than what OpenBSD releases/snapshots ship > with. Hi Jonathan, Thanks for the detailed answer! As best I can tell from wading through the mess of marketing names and specifications, accelerated 4k video is currently not an option with Radeon cards; the older cards don't support high-enough resolutions, and the newer ones don't have acceleration support yet due to the Mesa problem. Looks like I might need to buy an Intel machine or wait for the Mesa issues to get resolved. Thanks again, Joe -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
dmesg for ThinkPad T480s
This is the dmesg for my new ThinkPad T480s. Detailed specs: Intel Core i5-8250U LG 14.0" WQHD (2560 x 1440) IPS 16 GB DDR4 2400MHz Integrated Intel® UHD Graphics 620 IR 720p HD Camera with microphone NO Fingerprint Reader NO NFC Smartcard reader 512 GB SSD Samsung PM981 PCIe-NVMe M.2 3 cell Li-Ion 57Wh 65W AC Adapter USB Type-C Intel Dual Band 8265 Wireless AC & Bluetooth NO WWAN card Black dmesg (running -current): OpenBSD 6.3-current (GENERIC.MP) #206: Wed Apr 18 10:11:07 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17052938240 (16262MB) avail mem = 16528203776 (15762MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x9a65 (62 entries) bios0: vendor LENOVO version "N22ET34W (1.11 )" date 03/13/2018 bios0: LENOVO 20L7CTO1WW acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT SSDT BOOT BATB SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 MSDM DMAR ASF! FPDT UEFI acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 1397.32 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,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 1147.14 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,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: failed to identify cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 969.69 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,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBPcpu2: failed to identify ,SENSOR,ARAT,MELTDOWNcpu3 at mainbus0 : cpu2: 256KB 64b/line apid 6 (application processor) 8-way L2 cache cpu3: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 897.92 MHz cpu3: FPU,VME,DEcpu2: smt 0, core 2, package 0 ,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,ITSCcpu3: failed to identify ,FSGSBASE,SGX,BMI1,AVX2cpu4 at mainbus0,SMEP: apid 1 (application processor) ,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu3: 256KB 64b/line cpu4: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 897.92 MHz cpu4: 8-way L2 cache FPU,VME,DEcpu3: smt 0, core 3, package 0 ,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,POPCNTcpu4: failed to identify ,DEADLINE,AEScpu5 at mainbus0,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB: ,RDTSCP,LONGapid 3 (application processor) ,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBPcpu5: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 897.92 MHz cpu5:
Re: 4-ports router under $150
On 08/04/2018 23:16, Rupert Gallagher wrote: > 963Mbps > > On Sun, Apr 8, 2018 at 18:02, Michael Pricewrote: > >> Was it an apu2c4 by any chance? I was thinking about picking one of those up >> and was curious as to what kind of packet rates people were seeing with them. Obtaining a gig isn't hard, what actual pps can they achieve?
frozen clock on Intel NUC
I have tried to submit this to bugs@ twice in the past two days, once directly via sendbug and again by webmail, but as far as I can tell, it has not been accepted. Posting here in the hopes of making some devs aware of this issue... >Synopsis: Recent TSC changes seem to result in frozen clock on Intel NUC >Category: kernel >Environment: System : OpenBSD 6.2 Details : OpenBSD 6.2-current (GENERIC.MP) #148: Fri Oct 13 16:30:01 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: After upgrading to a recent snapshot, I noticed the following line in dmesg and a frozen clock once the system was up: acpitimer0: recalibrated TSC frequency -1 Hz I believe this is due to the recent TSC timecounter changes committed by mikeb. >How-To-Repeat: Happens all the time with current snapshot. >Fix: Disabling acpitimer in UKC is enough to bring the system up with a functional clock. dmesg: OpenBSD 6.2-current (GENERIC.MP) #148: Fri Oct 13 16:30:01 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Real mem = 4192968704 (3998MB) avail mem = 4059029504 (3870MB) User Kernel Config UKC> disable acpiti,\^H \^Hmer 387 acpitimer* disabled UKC> quit Continuing... mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xedcb0 (49 entries) bios0: vendor Intel Corp. version "PYBSWCEL.86A.0058.2016.1102.1842" date 11/02/2016 bios0: Intel Corporation NUC5CPYB acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI LPIT TPM2 CSRT SSDT acpi0: wakeup devices BRCM(S0) XHC1(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) acpitimer at acpi0 not configured acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU N3050 @ 1.60GHz, 1680.45 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu0: 1MB 64b/line 16-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 79MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 4 (application processor) cpu1: Intel(R) Celeron(R) CPU N3050 @ 1.60GHz, 1600.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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu1: 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 2, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP02) acpiprt3 at acpi0: bus 3 (RP03) acpiprt4 at acpi0: bus -1 (RP04) acpiec0 at acpi0: not present acpicpu0 at acpi0 C2: state 6: substate 8 >= num 3 C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS acpicpu1 at acpi0 C2: state 6: substate 8 >= num 3 C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: ID3C, resource for ISP3 acpipwrres1 at acpi0: CLK0, resource for CAMD acpipwrres2 at acpi0: CLK0 acpipwrres3 at acpi0: CLK1, resource for CAM3 acpipwrres4 at acpi0: USBC, resource for XHC1 acpipwrres5 at acpi0: FN00, resource for FAN0 acpitz0 at acpi0: critical temperature is 115 degC chvgpio0 at acpi0: GPO1 uid 2 addr 0xfed88000/0x8000 irq 48, 59 pins "ITE8713" at acpi0 not configured "BCM43241" at acpi0 not configured sdhc0 at acpi0: SDHC addr 0x81429000/0x1000 irq 47 sdhc0: SDHC 3.0, 200 MHz base clock sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed, dma "INTL9C60" at acpi0 not configured "INTL9C60" at acpi0 not configured "8086228A" at acpi0 not configured "8086228A" at acpi0 not configured dwiic0 at acpi0: I2C6 addr 0x81425000/0x1000 irq 37 iic0 at dwiic0 dwiic1 at acpi0: I2C7 addr 0x81423000/0x1000 irq 38 iic1 at dwiic1 acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: SLPB chvgpio1 at acpi0: GPO0 uid 1 addr 0xfed8/0x8000 irq 49, 56 pins chvgpio2 at acpi0: GPO2 uid 3 addr 0xfed9/0x8000 irq 50, 24 pins chvgpio3 at acpi0: GPO3 uid 4 addr 0xfed98000/0x8000 irq 91, 55 pins "MSFT0101" at acpi0 not configured "INT3398" at acpi0 not configured "PNP0C0B" at acpi0 not configured acpivideo0 at acpi0: GFX0 cpu0: Enhanced SpeedStep 1680 MHz: speeds: 1601, 1600, 1520, 1440, 1360, 1280, 1200, 1120, 1040, 960, 880, 800, 720, 640, 560, 480 MHz pci0 at mainbus0 bus 0
Re: Blocking users who change their IP address
On 05/10/2017 22:39, Eric Johnson wrote: On Fri, 6 Oct 2017, Mihai Popescu wrote: I'm at a small Wireless ISP in a small town and have only a Class C block of addresses. [...] [...] Very romantic, indeed, but it has nothing to do with OpenBSD. Are you serious? Since the primary firewall and the DHCP server (and pretty much everything else on my end) run on OpenBSD, if there is a way to do it with OpenBSD, for example with pf, then I think that it should be a very good place to ask the question. Of course, if there is no way to address the problem on computers running OpenBSD, then I did ask in the wrong place. Based on your response, I assume that OpenBSD must be useless for trying to solve that problem and I shall have to look elsewhere. Eric This is a network infrastructure/design problem you need to either isolate customers or filter further down stream, if they're on a relatively dumb shared layer2 network you aren't going to be able to fix it by the time it gets to the firewall...
Re: Yubikey works on gpg1 but not gpg2
Hi Carolyn, I had the same behavior when I tried this on -current but it was working well as supposed on -stable Thus, my first thought was that the current version of the GnuPG 2 package was the culprit, but to be sure I tried to see if I could access the smartcard to discard first the drivers. So I installed the pcsc-tools package and tried to scan the smartcard: $ pcsc_scan PC/SC device scanner ... SCardEstablishContext: Service not available. Now the error was clear, the pcscd daemon wasn't running. The solution was easy, enable it and start it: # rcctl enable pcscd # rcctl start pcscd And that's it! You need the ccid and pcsc-tools packages installed in order to use a smartcard. P.S. Anyway, both of us could have saved time and troubles if we had read the readme file of the package in /usr/local/share/doc/pkg-readmes where exactly this is explained and also there is an example with a Yubikey. My bad, I'm starting with OpenBSD coming from a looong time on Linux and I don't know all the OB' bolts and nuts yet ;) Regards, El 7 de agosto de 2017 7:09:32 CEST, Carolyn Saundersescribió: >I have a Yubikey that I'd like to use for gpg and ssh purposes. Running >"gpg --card-status" works as expected; it brings up the various keys >attached to the device and other information. However, running "gpg2 >--card-status" just hangs, seemingly forever. What am I missing here? >Thanks :)
KARL broken on arm64?
I just dusted off my Raspberry Pi 3 and updated to the latest snapshot (from this morning). /usr/share/compile/GENERIC/relink.log shows: (SHA256) /bsd: OK LD="ld" sh makegap.sh 0xd4d4d4d4 gapdummy.o ld: error: gap.link:11: unknown command ; ld: error: gap.link:11: LONG(0xd4d4d4d4); ld: error: gap.link:11: ^ ld: error: cannot open gapdummy.o: No such file or directory ld: error: target emulation unknown: -m or at least one .o file required *** Error 1 in /usr/share/compile/GENERIC (Makefile:529 'newbsd') Known issue? Worthy of a bug report? Thanks, -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
Re: Dynamic DNS Client for EasyDNS
> "Joe Gidi" <j...@entropicblur.com> wrote: > >> ddclient should fit the bill. It's Perl, it's in ports, and it supports >> EasyDNS. I've used it for a few years now with no problems. >> >> Joe > > Thanks for the quick response. Although I really like Ryan Flannery > answer I think I got this already working. > > Joe could you please confirm that I don't need to do anything on EasyDNS > side if I use ddclient? It looks like after I set up the method of > updating ip in ddclient.conf and edit the EasyDNS configuration > paragraph with my username and password I am good to go as it looks like > ddclient is going to edit zone files for me. > > Predrag I'm using ddclient with a different DNS service, but yes, all I had to do was set up ddclient.conf and enable ddclient with rcctl. -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
Re: Dynamic DNS Client for EasyDNS
ddclient should fit the bill. It's Perl, it's in ports, and it supports EasyDNS. I've used it for a few years now with no problems. Joe > One of my clients is insisting on using her current ISP with dynamic IP. > On the another hand we decided to use EasyDNS as our managed DNS > provider due to my past experiences with them. She bought DNS pro plan > which does include among other things Dynamic DNS services. However I > see that only ez-ipupdate is listed as Dynamic DNS client. Apart of the > fact that it is not in OpenBSD port tree I see that it is written in C > (I was hoping for a simple Perl script) > > https://sourceforge.net/projects/ez-ipupdate/ > > and officially untested on anything else besides Linux. I see FreeBSD > port > > https://www.freebsd.org/cgi/ports.cgi?query=ez-ipupdate=all=all > > Short of me convincing the client to buy statis IP or porting > ez-ipupdate to OpenBSD does anyone see any other alternatives? > > Best, > Predrag > > -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
Re: octeon port, ubiquity edgerouter
On 26/07/2017 00:56, jungle Boogie wrote: > On 25 July 2017 at 15:20, Doggiewrote: >> W dniu 2017-07-25 o 19:39, Peter J. Philipp pisze: >>> >>> Actually I bought the silent fans. So I don't have to write any code, >>> too bad the foxconn fans are a misdesign. I'll maintenance this router >>> next week for the new fans. I'm putting it into production at home >>> tomorrow though. >> >> >> Thanks for all the details, Peter, and good luck during next steps of your >> project. >> >> I wonder how fast the NIC's will be - using this CPU and still no hardware >> acceleration. >> > > Yeah, I'm wondering that too. It's pretty cool this platform is > becoming more popular to run openBSD on. > People are willing to take an unknown (right now) performance penalty > to run openBSD on it and with pf. > > Sounds like ubiquity should just sell it with openBSD loaded on it > support the project. ;) > As far as the ERL goes, it seems to be limited to about 250Mbps per interface (only tested with in+out, 2 500 ish total), regardless of packet size
Re: Jumbo frames on Octeon
On 29/06/2017 12:06, Visa Hankala wrote: > On Tue, Jun 27, 2017 at 07:57:42PM +0100, Joe Holden wrote: >> It looks like setting the mtu on cnmac interfaces doesn't quite work as >> expected, whatever the mtu is set to the upper limit appears to be 1510 >> as although it will transmit frames of any arbitary size (e.g 2000 >> bytes), the reply never makes it back (confirmed from an attached box) >> unless the frame is =< 1510. > I just committed a patch that lets MTU change happen on the fly > with cnmac(4). > > If you are using release 6.1, you have to temporarily bring down > the interface, or reboot, when changing MTU on a cnmac(4) interface. > Ah excellent, cheers!
Re: Jumbo frames on Octeon
On 27/06/2017 19:57, Joe Holden wrote: > Hi guys, > > It looks like setting the mtu on cnmac interfaces doesn't quite work as > expected, whatever the mtu is set to the upper limit appears to be 1510 > as although it will transmit frames of any arbitary size (e.g 2000 > bytes), the reply never makes it back (confirmed from an attached box) > unless the frame is =< 1510. > > Not sure who looks after octeon these days > > Cheers > Should probably note, observed on ERL
Jumbo frames on Octeon
Hi guys, It looks like setting the mtu on cnmac interfaces doesn't quite work as expected, whatever the mtu is set to the upper limit appears to be 1510 as although it will transmit frames of any arbitary size (e.g 2000 bytes), the reply never makes it back (confirmed from an attached box) unless the frame is =< 1510. Not sure who looks after octeon these days Cheers
Re: DNS hijacking (was Re: Is this an intrusion?)
On 18/06/2017 10:59, Stuart Henderson wrote: > On 2017-06-17, Paul Suhwrote: >> Folks,=20 >> >> My understanding of the way that this is done is by returning a CNAME = >> when the ISP's DNS recursive DNS server would otherwise return a = >> NXDOMAIN result, followed by a HTTP 302 when the browser attempts to = >> reach the host via the bogus CNAME.=20 >> >> My question is would running my own internal recursive DNS resolver be = >> sufficient to stop this from happening? (I run my own DNS server anyway, = >> but I'm curious to see whether it would be sufficient to bypass the = >> search page redirection stupidity.)=20 > > Usually that's enough, but it depends how evil the ISP is. > Should give them a call and have it turned off anyway really...
Re: Is this an intrusion?
On 16/06/2017 20:59, Maurice McCarthy wrote: > On 15/06/17 14:13, Ted Unangst wrote: >> Maurice McCarthy wrote: >>> Hi, >>> >>> $ xauth list >>> ... >>> advancedsearch.virginmedia.com:0 MIT-MAGIC-COOKIE-1 >>> f3aa08ed0926482c51f5cb386e28a0ea >>> >>> >>> Virgin Media is my ISP. Is this an intrusion into my system please? I >>> ran xauth remove ... just for the sake of it anyhow. >> >> well, even if it wasn't, you just posted the secret key to a public list, so >> probably wise to remove it anyway. :) > > Thanks to all that have replied and apologies for the slow response. Had > to attend to more urgent matters. (Lost the blessed terrestrial TV > signal!) > > To TedU, > > Ooops! ... Well, I moved the .Xauthority file aside and restarted X to > create a new one. Obviously it has one line with my hostname in it. But > > $ xauth list > fresh.yem/unix:0 MIT-MAGIC-COOKIE-1 ... > advancedsearch.virginmedia.com:0 MIT-MAGIC-COOKIE-1 ... > > And only now did I notice that the magic cookie is identical for both > entries. This mystifies me. (BTW apparently Virgin has historically used > a bit of DNS hijacking so I bunged this line into /etc/hosts before > restarting X. > > 127.0.0.1 advancedsearch.virginmedia.com ) > > > To Peter Hessler, > > The reverse DNS went like this > > 80.2.249.209 cpc77525-cwma10-2-0-cust208.7-3.cable.virginm.net > > I run most traffic through a vpn but my router is a Virgin SuperHub2, as > they call it. > > > To Dot Yet, > > I've through system logs etc and nothing seems to look suspicious. Can't > find any attempts to execute commands nor authenticate. Further the > remote access port is disabled in the router settings. I've never asked > Virgin for support in years. > > > To Joe Holden, > > Thanks for the tip about NXDOMAIN queries. Don't see where to unset in > the router but I'm guessing the hosts file entry above should do the > same thing. > > I'll keep looking around to reassure myself anyhow > > Thanks to all, > Moss It is done by the VM dns servers, if you visit a domain that doesn't exist you should be directed to the advanced search page, there *should* be a link to disable it there, but if not login to your account and disable it, can't remember what it is called... Hosts file won't solve the problem really since anything else will also get the same result
Re: Is this an intrusion?
On 15/06/2017 16:47, Dot Yet wrote: > On Thu, Jun 15, 2017 at 9:12 AM Maurice McCarthy> wrote: > >> Hi, >> >> $ xauth list >> ... >> advancedsearch.virginmedia.com:0 MIT-MAGIC-COOKIE-1 >> f3aa08ed0926482c51f5cb386e28a0ea >> >> >> Virgin Media is my ISP. Is this an intrusion into my system please? I >> ran xauth remove ... just for the sake of it anyhow. >> >> Thanks >> Moss > > > Maybe. Are there other hints in the system log files, history files around >> someone trying to authenticate or execute commands? Was there a possibility >> that there was a screen sharing session done for any kind of support >> activities (would not be the case as you are already suspecting intrusion). >> More likely you typo'd adding a host, advancedsearch is what NXDOMAIN queries get directed to, just turn it off on my virgin media
Re: Can I bind USB/other interface/device number (e.g. cdceX) to particular MAC, USB serial number or the like?
Good news! You can have this already. Go run Linux. On June 1, 2017 8:42:45 PM EDT, Tinkerwrote: >Ah - having an interface name naming scheme that, instead of just being > >a counter, e.g. CDCE + 0 -> 1 -> ... = "cdce0", denoting the physical >slot where the device is connected, e.g. CDCE + USB root-hub: 0 + slot: > >17 + address: 4 = "cdceur0s17a4", would do the job too. > >On 2017-06-02 00:24, Tinker wrote: >> Hi, >> >> What I meant was, it's fairly easy for interface numbers (e.g. NIC A >> as CDCE0 and NIC B as CDCE1) to become exchanged. >> >> With lots of unluck, there could be mechanical stress on USB ports so >> that they would rearrange spontaneously so NIC B would become CDCE0 >> and NIC A would become CDCE1. >> >> Or more probable, an ignorant user would intentionally replug his >> devices but the change of order of interfaces would be unintentional >> to him, and then when he ifconfig/dhclient:s his interfaces, very bad >> things could happen. >> >> This is not a big deal, but it does add one more thing to think >about, >> and in extreme corner cases it could be a security problem - God >> forbid you'd have a public network on CDCE0 and a private network on >> CDCE1 and then a little mistake causes everyone's medical records >etc. >> to be leaked on the Internet. >> >> >> The same would apply to USB serial ports (UART:s) and probably some >> other hardware - >> >> I was talking to someone who was worried that it (unintended device >> ordering) could happen even to PCI devices though I guess that's >> overkill. >> >> His solution is to enforce device names by using different hardware, >> though that kind of illustrates the problem rather than resolve it, >> doesn't it. >> >> >> OpenBSD leaves IP configuration as manual work to the user so OpenBSD >> itself won't mess it up for you, so this is not a per-se OpenBSD >> problem. >> >> But maybe OpenBSD could help people do it right. Interface number >> hard-binding to a particular device descriptor (MAC/USB serial etc.) >> would solve it. >> >> Interface name aliasing would work too (hardbound to descriptor). >> >> >> Anyhow I just wanted to bring up the potential problem. >> >> (Also Peter - this is not specifically a PF problem, however, how >> would you use egress as part of the solution?) >> >> Thanks, >> Tinker >> >> On 2017-05-30 07:04, Peter Hessler wrote: >>> On 2017 May 29 (Mon) at 02:13:57 + (+), Tinker wrote: >>> :Hi misc@, >>> : >>> :For pluggable devices such as USB NIC:s, is there any way to make >>> OpenBSD >>> :bind a particular device based on its MAC or USB serial number or >the >>> like >>> :variable, to a particular interface or device filename? >>> : >>> :E.g. MAC X is prebooked as cdce0, and MAC Y as cdce1 , and external > >>> USB >>> :harddrive with serial number Z as /dev/sd0 and the one with serial >>> number A >>> :as /dev/sd1 (and plugging in other devices would automatically). >>> : >>> :(For storage devices there's the DUID-based mounting already >though, >>> so I >>> :guess those are a non-issue.) >>> : >>> :Some things in the OS are specified per interface/device name, e.g. > >>> PF rules >>> :(e.g. "pass in proto tcp from any to cdce0 port 123 rdr-to cdce1 >..", >>> "match >>> :out on cdce0 from 192.168.0.0/16 to any nat-to cdce0"), so having >the >>> :interface numbers garbled on replug may be an unnecessary reason to > >>> reboot? >>> : >>> :Would be happy to learn any best practice here, thanks, >>> :Tinker >>> : >>> >>> match out on egress from 192.168.0.0/16 to any nat-to (egress) >>> ^^ >>> >>> the interface group "egress" is added to the interface a default >route >>> uses. Wrapping that with (), will ensure that interface is updated >>> when >>> the default routes uses a different interface. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Small patch for vnconfig/mount_vnd to return the first unused vnd device
Might be useful, particularly in scripting... Behaves like losetup. Index: sbin/mount_vnd/mount_vnd.c === RCS file: /cvs/src/sbin/mount_vnd/mount_vnd.c,v retrieving revision 1.20 diff -u -p -r1.20 mount_vnd.c --- sbin/mount_vnd/mount_vnd.c 24 Jan 2016 06:32:33 - 1.20 +++ sbin/mount_vnd/mount_vnd.c 28 Apr 2017 03:24:44 - @@ -62,6 +62,7 @@ #define VND_CONFIG 1 #define VND_UNCONFIG 2 #define VND_GET3 +#define VND_FIND 4 int verbose = 0; int run_mount_vnd = 0; @@ -70,12 +71,13 @@ __dead void usage(void); int config(char *, char *, int, struct disklabel *, char *, size_t); int getinfo(const char *); +int findfirst(void); char *get_pkcs_key(char *, char *); int main(int argc, char **argv) { - int ch, rv, action, opt_c, opt_k, opt_K, opt_l, opt_u; + int ch, rv, action, opt_c, opt_k, opt_K, opt_l, opt_u, opt_f = 0; char*key, *mntopts, *rounds, *saltopt; size_t keylen = 0; extern char *__progname; @@ -88,7 +90,7 @@ main(int argc, char **argv) key = mntopts = rounds = saltopt = NULL; action = VND_CONFIG; - while ((ch = getopt(argc, argv, "ckK:lo:S:t:uv")) != -1) { + while ((ch = getopt(argc, argv, "ckK:lo:S:t:uv:f")) != -1) { switch (ch) { case 'c': opt_c = 1; @@ -103,6 +105,9 @@ main(int argc, char **argv) case 'l': opt_l = 1; break; + case 'f': + opt_f = 1; + break; case 'o': mntopts = optarg; break; @@ -133,6 +138,8 @@ main(int argc, char **argv) if (opt_l) action = VND_GET; + else if (opt_f) + action = VND_FIND; else if (opt_u) action = VND_UNCONFIG; else @@ -173,6 +180,8 @@ main(int argc, char **argv) rv = config(argv[0], NULL, action, NULL, NULL, 0); else if (action == VND_GET) rv = getinfo(argc ? argv[0] : NULL); + else if (action == VND_FIND) + rv = findfirst(); else usage(); @@ -290,6 +299,35 @@ query: close(vd); return (0); +} + +int +findfirst(void) +{ + char *vname = DEFAULT_VND; + int vd; + struct vnd_user vnu; + + vd = opendev((char *)vname, O_RDONLY, OPENDEV_PART, NULL); + if (vd < 0) + err(1, "open: %s", vname); + + vnu.vnu_unit = -1; + +query: + if (ioctl(vd, VNDIOCGET, ) == -1) + err(1, "ioctl: %s", vname); + + if (!vnu.vnu_ino) + fprintf(stdout, "vnd%d\n", vnu.vnu_unit); + else { + vnu.vnu_unit++; + goto query; + } + + close(vd); + + return (0); } int (cvs diff is dumb)
Re: Setting rtable 0 from >1 with ping et al
On 18/03/2017 08:21, Florian Obser wrote: On Thu, Mar 16, 2017 at 07:59:44PM +, Joe Holden wrote: On 09/03/2017 23:35, Joe Holden wrote: On 09/03/2017 23:02, Joe Holden wrote: Hi, So - it seems that pledge will deny a change of rtable to 0 when using level SOL_SOCKET and the current rtable is >0, so eg if you're in table 1 and you do ping -V0 it will fail. Can anyone shed any light on why this is restricted? Especially since the same can be achieved with route -T0 exec Thanks! Actually, just realised why it doesn't work - it drops privs before setting rtable, nevermind. Something like: Index: sbin/ping/ping.c === RCS file: /cvs/src/sbin/ping/ping.c,v retrieving revision 1.218 diff -u -p -r1.218 ping.c --- sbin/ping/ping.c22 Feb 2017 13:43:35 - 1.218 +++ sbin/ping/ping.c16 Mar 2017 19:58:28 - @@ -283,10 +283,6 @@ main(int argc, char *argv[]) uid = getuid(); gid = getgid(); } - if (setgroups(1, ) || - setresgid(gid, gid, gid) || - setresuid(uid, uid, uid)) - err(1, "unable to revoke privs"); preload = 0; datap = [ECHOLEN + ECHOTMLEN]; @@ -427,6 +423,11 @@ main(int argc, char *argv[]) usage(); } } + + if (setgroups(1, ) || + setresgid(gid, gid, gid) || + setresuid(uid, uid, uid)) + err(1, "unable to revoke privs"); argc -= optind; argv += optind; perhaps, but haven't closely looked if there is any scope for escalation or anything during option parsing This seems... unwise. ping(8) very carefuly tries to do as little as possible while still having priviledges, i.e. only create raw sockets. That being said, I don't understand the problem. 1) How do you end up in rtable 1 and need to do something in table 0? In this instance, the management (sshd, et al) rtable isn't 0 (for a few reasons, mostly things that can't operate on an rtable other than 0) 2) you say route -T0 exec works, I don't think so: $ route -T1 exec /bin/sh $ route -T0 exec ping 8.8.8.8 route: setrtable: Operation not permitted setrtable(2) has this: ERRORS The call succeeds unless: [...] [EPERM]The user is not the superuser and the routing table of the calling process is already set to a non-zero value. So this is intentional behaviour. Setting rtable implies being uid 0, so not really - but: # ping -V0 127.0.0.1 ping: setsockopt SO_RTABLE: Operation not permitted # route -T0 exec ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.948 ms from an rtable other than 0, because the route doesn't use SO_RTABLE so doesn't fail
bioctl showing "0% done" on apparently healthy softraid
cpi0: FN01, resource for FAN1 acpipwrres2 at acpi0: FN02, resource for FAN2 acpipwrres3 at acpi0: FN03, resource for FAN3 acpipwrres4 at acpi0: FN04, resource for FAN4 acpitz0 at acpi0: critical temperature is 105 degC acpitz1 at acpi0: critical temperature is 105 degC "INT3F0D" at acpi0 not configured "PNP0501" at acpi0 not configured acpibtn0 at acpi0: PWRB "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C14" at acpi0 not configured acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: Enhanced SpeedStep 3193 MHz: speeds: 3201, 3200, 3000, 2900, 2700, 2500, 2300, 2200, 2000, 1800, 1700, 1500, 1300, 1100, 1000, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Xeon E3-1200 v3 Host" rev 0x06 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics P4600" rev 0x06 drm0 at inteldrm0 inteldrm0: msi inteldrm0: 1024x768, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) azalia0 at pci0 dev 3 function 0 "Intel Core 4G HD Audio" rev 0x06: msi xhci0 at pci0 dev 20 function 0 "Intel 8 Series xHCI" rev 0x05: msi usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 "Intel 8 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 "Intel I217-LM" rev 0x05: msi, address 6c:0b:84:09:f9:bd ehci0 at pci0 dev 26 function 0 "Intel 8 Series USB" rev 0x05: apic 8 int 17 usb1 at ehci0: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia1 at pci0 dev 27 function 0 "Intel 8 Series HD Audio" rev 0x05: msi azalia1: codecs: Realtek ALC662 audio0 at azalia1 ppb0 at pci0 dev 28 function 0 "Intel 8 Series PCIE" rev 0xd5 pci1 at ppb0 bus 1 ppb1 at pci0 dev 28 function 1 "Intel 8 Series PCIE" rev 0xd5: msi pci2 at ppb1 bus 2 em1 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 68:05:ca:3a:8e:b2 ppb2 at pci0 dev 28 function 3 "Intel 8 Series PCIE" rev 0xd5: msi pci3 at ppb2 bus 3 ppb3 at pci3 dev 0 function 0 "ITExpress IT8893E PCIE-PCI" rev 0x41 pci4 at ppb3 bus 4 ehci1 at pci0 dev 29 function 0 "Intel 8 Series USB" rev 0x05: apic 8 int 23 usb2 at ehci1: USB revision 2.0 uhub2 at usb2 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 pcib0 at pci0 dev 31 function 0 "Intel C226 LPC" rev 0x05 ahci0 at pci0 dev 31 function 2 "Intel 8 Series AHCI" rev 0x05: msi, AHCI 1.3 ahci0: port 0: 6.0Gb/s ahci0: port 1: 6.0Gb/s ahci0: port 2: 6.0Gb/s ahci0: port 3: 6.0Gb/s ahci0: port 4: 1.5Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: <ATA, Samsung SSD 850, EMT0> SCSI3 0/direct fixed naa.5002538d4019e022 sd0: 238475MB, 512 bytes/sector, 488397168 sectors, thin sd1 at scsibus1 targ 1 lun 0: <ATA, ST4000VN000-1H41, SC46> SCSI3 0/direct fixed naa.5000c50079458b1b sd1: 3815447MB, 512 bytes/sector, 7814037168 sectors sd2 at scsibus1 targ 2 lun 0: <ATA, ST4000VN000-1H41, SC46> SCSI3 0/direct fixed naa.5000c500799ccc22 sd2: 3815447MB, 512 bytes/sector, 7814037168 sectors sd3 at scsibus1 targ 3 lun 0: <ATA, ST4000VN000-1H41, SC46> SCSI3 0/direct fixed naa.5000c500794576ca sd3: 3815447MB, 512 bytes/sector, 7814037168 sectors cd0 at scsibus1 targ 4 lun 0: <HL-DT-ST, DVD-ROM DTA0N, DC01> ATAPI 5/cdrom removable ichiic0 at pci0 dev 31 function 3 "Intel 8 Series SMBus" rev 0x05: apic 8 int 18 iic0 at ichiic0 sdtemp0 at iic0 addr 0x19: mcp98243 spdmem0 at iic0 addr 0x51: 4GB DDR3 SDRAM ECC PC3-12800 with thermal sensor isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 vmm disabled by firmware vmm at mainbus0 not configured error: [drm:pid0:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt uhub3 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 2.00/0.05 addr 2 uhub4 at uhub2 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 2.00/0.05 addr 2 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets sd4 at scsibus3 targ 1 lun 0: <OPENBSD, SR RAID 1, 006> SCSI2 0/direct fixed sd4: 3815447MB, 512 bytes/sector, 7814036576 sectors root on sd0a (918dcdbb8c221cb4.a) swap on sd0b dump on sd0b Thanks, -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
bioctl showing "0% done" on apparently healthy softraid
.1), PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpipwrres1 at acpi0: FN01, resource for FAN1 acpipwrres2 at acpi0: FN02, resource for FAN2 acpipwrres3 at acpi0: FN03, resource for FAN3 acpipwrres4 at acpi0: FN04, resource for FAN4 acpitz0 at acpi0: critical temperature is 105 degC acpitz1 at acpi0: critical temperature is 105 degC "INT3F0D" at acpi0 not configured "PNP0501" at acpi0 not configured acpibtn0 at acpi0: PWRB "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C0B" at acpi0 not configured "PNP0C14" at acpi0 not configured acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: Enhanced SpeedStep 3193 MHz: speeds: 3201, 3200, 3000, 2900, 2700, 2500, 2300, 2200, 2000, 1800, 1700, 1500, 1300, 1100, 1000, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Xeon E3-1200 v3 Host" rev 0x06 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics P4600" rev 0x06 drm0 at inteldrm0 inteldrm0: msi inteldrm0: 1024x768, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) azalia0 at pci0 dev 3 function 0 "Intel Core 4G HD Audio" rev 0x06: msi xhci0 at pci0 dev 20 function 0 "Intel 8 Series xHCI" rev 0x05: msi usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 "Intel 8 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 "Intel I217-LM" rev 0x05: msi, address 6c:0b:84:09:f9:bd ehci0 at pci0 dev 26 function 0 "Intel 8 Series USB" rev 0x05: apic 8 int 17 usb1 at ehci0: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia1 at pci0 dev 27 function 0 "Intel 8 Series HD Audio" rev 0x05: msi azalia1: codecs: Realtek ALC662 audio0 at azalia1 ppb0 at pci0 dev 28 function 0 "Intel 8 Series PCIE" rev 0xd5 pci1 at ppb0 bus 1 ppb1 at pci0 dev 28 function 1 "Intel 8 Series PCIE" rev 0xd5: msi pci2 at ppb1 bus 2 em1 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 68:05:ca:3a:8e:b2 ppb2 at pci0 dev 28 function 3 "Intel 8 Series PCIE" rev 0xd5: msi pci3 at ppb2 bus 3 ppb3 at pci3 dev 0 function 0 "ITExpress IT8893E PCIE-PCI" rev 0x41 pci4 at ppb3 bus 4 ehci1 at pci0 dev 29 function 0 "Intel 8 Series USB" rev 0x05: apic 8 int 23 usb2 at ehci1: USB revision 2.0 uhub2 at usb2 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 pcib0 at pci0 dev 31 function 0 "Intel C226 LPC" rev 0x05 ahci0 at pci0 dev 31 function 2 "Intel 8 Series AHCI" rev 0x05: msi, AHCI 1.3 ahci0: port 0: 6.0Gb/s ahci0: port 1: 6.0Gb/s ahci0: port 2: 6.0Gb/s ahci0: port 3: 6.0Gb/s ahci0: port 4: 1.5Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: <ATA, Samsung SSD 850, EMT0> SCSI3 0/direct fixed naa.5002538d4019e022 sd0: 238475MB, 512 bytes/sector, 488397168 sectors, thin sd1 at scsibus1 targ 1 lun 0: <ATA, ST4000VN000-1H41, SC46> SCSI3 0/direct fixed naa.5000c50079458b1b sd1: 3815447MB, 512 bytes/sector, 7814037168 sectors sd2 at scsibus1 targ 2 lun 0: <ATA, ST4000VN000-1H41, SC46> SCSI3 0/direct fixed naa.5000c500799ccc22 sd2: 3815447MB, 512 bytes/sector, 7814037168 sectors sd3 at scsibus1 targ 3 lun 0: <ATA, ST4000VN000-1H41, SC46> SCSI3 0/direct fixed naa.5000c500794576ca sd3: 3815447MB, 512 bytes/sector, 7814037168 sectors cd0 at scsibus1 targ 4 lun 0: <HL-DT-ST, DVD-ROM DTA0N, DC01> ATAPI 5/cdrom removable ichiic0 at pci0 dev 31 function 3 "Intel 8 Series SMBus" rev 0x05: apic 8 int 18 iic0 at ichiic0 sdtemp0 at iic0 addr 0x19: mcp98243 spdmem0 at iic0 addr 0x51: 4GB DDR3 SDRAM ECC PC3-12800 with thermal sensor isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 vmm disabled by firmware vmm at mainbus0 not configured error: [drm:pid0:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt uhub3 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 2.00/0.05 addr 2 uhub4 at uhub2 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 2.00/0.05 addr 2 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets sd4 at scsibus3 targ 1 lun 0: <OPENBSD, SR RAID 1, 006> SCSI2 0/direct fixed sd4: 3815447MB, 512 bytes/sector, 7814036576 sectors root on sd0a (918dcdbb8c221cb4.a) swap on sd0b dump on sd0b -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
Re: Setting rtable 0 from >1 with ping et al
On 09/03/2017 23:35, Joe Holden wrote: On 09/03/2017 23:02, Joe Holden wrote: Hi, So - it seems that pledge will deny a change of rtable to 0 when using level SOL_SOCKET and the current rtable is >0, so eg if you're in table 1 and you do ping -V0 it will fail. Can anyone shed any light on why this is restricted? Especially since the same can be achieved with route -T0 exec Thanks! Actually, just realised why it doesn't work - it drops privs before setting rtable, nevermind. Something like: Index: sbin/ping/ping.c === RCS file: /cvs/src/sbin/ping/ping.c,v retrieving revision 1.218 diff -u -p -r1.218 ping.c --- sbin/ping/ping.c22 Feb 2017 13:43:35 - 1.218 +++ sbin/ping/ping.c16 Mar 2017 19:58:28 - @@ -283,10 +283,6 @@ main(int argc, char *argv[]) uid = getuid(); gid = getgid(); } - if (setgroups(1, ) || - setresgid(gid, gid, gid) || - setresuid(uid, uid, uid)) - err(1, "unable to revoke privs"); preload = 0; datap = [ECHOLEN + ECHOTMLEN]; @@ -427,6 +423,11 @@ main(int argc, char *argv[]) usage(); } } + + if (setgroups(1, ) || + setresgid(gid, gid, gid) || + setresuid(uid, uid, uid)) + err(1, "unable to revoke privs"); argc -= optind; argv += optind; perhaps, but haven't closely looked if there is any scope for escalation or anything during option parsing
Hey
What's up, people? Compatibility should be equivalent to the architecture being used. Whatever the scenario, there will always be the necessity of creating layers of abstraction for security. One could create a jailed/chroot environment for the compat layer. The next step would be creating a virtual and headless machine. SSH keys would need to be created. Create files in other jailed environments. Connect to the jailed environment from the desktop. Yes, that is a lot, and, just on one side. People use the excuse of, "I need an incentive." No. You are going to do it when you want. Anyway, may all of you have a blessed and goodly day.
Re: Setting rtable 0 from >1 with ping et al
On 09/03/2017 23:02, Joe Holden wrote: Hi, So - it seems that pledge will deny a change of rtable to 0 when using level SOL_SOCKET and the current rtable is >0, so eg if you're in table 1 and you do ping -V0 it will fail. Can anyone shed any light on why this is restricted? Especially since the same can be achieved with route -T0 exec Thanks! Actually, just realised why it doesn't work - it drops privs before setting rtable, nevermind.
Setting rtable 0 from >1 with ping et al
Hi, So - it seems that pledge will deny a change of rtable to 0 when using level SOL_SOCKET and the current rtable is >0, so eg if you're in table 1 and you do ping -V0 it will fail. Can anyone shed any light on why this is restricted? Especially since the same can be achieved with route -T0 exec Thanks!
Re: Bizarre arp entry corruption
On 09/03/2017 11:51, Martin Pieuchot wrote: On 07/03/17(Tue) 19:38, Joe Holden wrote: On 12/12/2016 16:55, Joe Holden wrote: On 12/12/2016 10:27, Martin Pieuchot wrote: On 11/12/16(Sun) 00:50, Joe Holden wrote: On 10/12/2016 08:43, Mihai Popescu wrote: seeing some bizarre behaviour on one box, on one specific interface: Hello, This looks like some stupid TV game, where contesters are given some clues from time to time and they have to guess what is the real shit. Do post your FULL dmesg and configurations for network if you really want someone to even think at your issue. Isn't that obvious? Bye! Appreciate the useless response (but still better than nothing!), the affected box has since been reverted to older snapshot and thus no more debugging can be done - someone else will have to do it. I'd appreciate to see the output of 'netstat -rnf inet' when it is relevant. Without that information it's hard to understand. But there's a bug somewhere, it has to be fixed. Not that dmesg is even relevant since it is a userland bug not a kernel problem but anyway: It's a kernel problem. I'll see if I can recreate it but I'm not holding my breath - it only breaks once BGP loaded the table which leads me to thing it is actually bgpd that is updating the llinfo with bogus info and even though I have a feed in my lab it doesn't do the same thing. Ok so, inadvertantly recreated this (pretty much exactly the same) issue on a lab/test setup: For the purposes of debug, ignore the fact that the interfaces are tap interfaces, they're still emulated ethernet... Wall of text incoming, various info... box#1: tap1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr fe:e1:ba:d1:be:f3 index 7 priority 0 llprio 3 groups: tap status: active inet 172.20.230.72 netmask 0xfffe box#2: tap1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr fe:e1:ba:d1:cf:92 index 7 priority 0 llprio 3 groups: tap status: active inet 172.20.230.73 netmask 0xfffe All is fine after starting ospfd, but as soon as I start bgpd, box#2 shows the following: Host Ethernet AddressNetif Expire Flags 172.20.230.7200:00:00:00:20:12 ? 12m30s # route -n get 172.20.230.72 route to: 172.20.230.72 destination: 172.20.230.72 mask: 255.255.255.255 interface: tap1 if address: 172.20.230.73 priority: 3 () flags: <UP,HOST,DONE,LLINFO,CLONED,CACHED> use mtuexpire 20 0 702 flags destination gateway lpref med aspath origin IS*> 172.20.230.72/31 172.20.230.64 200 0 i .64 is the loopback on one of its connected boxes that doesn't have broken entries tcpdump looks ok, afterwards: 19:14:23.723876 arp who-has 172.20.230.72 tell 172.20.230.73 19:14:23.901883 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3 19:14:24.022948 arp who-has 172.20.230.72 tell 172.20.230.73 19:14:24.201095 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3 but the correct entry is never installed, after I delete the broken arp entry it never readds a new one. This only happens with redist connected as far as I can tell, but bgpd probably shouldn't be able to mangle arp entries and prevent the correct one being added. Here's the fix. Index: net/rtsock.c === RCS file: /cvs/src/sys/net/rtsock.c,v retrieving revision 1.232 diff -u -p -r1.232 rtsock.c --- net/rtsock.c7 Mar 2017 09:23:27 - 1.232 +++ net/rtsock.c8 Mar 2017 16:06:22 - @@ -895,10 +895,22 @@ rtm_output(struct rt_msghdr *rtm, struct } } change: - if (info->rti_info[RTAX_GATEWAY] != NULL && (error = - rt_setgate(rt, info->rti_info[RTAX_GATEWAY], - tableid))) - break; + if (info->rti_info[RTAX_GATEWAY] != NULL) { + /* +* When updating the gateway, make sure it's +* valid. +*/ + if (!newgate && rt->rt_gateway->sa_family != + info->rti_info[RTAX_GATEWAY]->sa_family) { + error = EINVAL; + break; + } + + error = rt_setgate(rt, + info->rti_info[RTAX_GATEWAY], tableid); + if (error) + break; + } #ifdef MPLS if ((rtm->rtm_flags & RTF_M
Re: Bizarre arp entry corruption
On 12/12/2016 16:55, Joe Holden wrote: On 12/12/2016 10:27, Martin Pieuchot wrote: On 11/12/16(Sun) 00:50, Joe Holden wrote: On 10/12/2016 08:43, Mihai Popescu wrote: seeing some bizarre behaviour on one box, on one specific interface: Hello, This looks like some stupid TV game, where contesters are given some clues from time to time and they have to guess what is the real shit. Do post your FULL dmesg and configurations for network if you really want someone to even think at your issue. Isn't that obvious? Bye! Appreciate the useless response (but still better than nothing!), the affected box has since been reverted to older snapshot and thus no more debugging can be done - someone else will have to do it. I'd appreciate to see the output of 'netstat -rnf inet' when it is relevant. Without that information it's hard to understand. But there's a bug somewhere, it has to be fixed. Not that dmesg is even relevant since it is a userland bug not a kernel problem but anyway: It's a kernel problem. I'll see if I can recreate it but I'm not holding my breath - it only breaks once BGP loaded the table which leads me to thing it is actually bgpd that is updating the llinfo with bogus info and even though I have a feed in my lab it doesn't do the same thing. Ok so, inadvertantly recreated this (pretty much exactly the same) issue on a lab/test setup: For the purposes of debug, ignore the fact that the interfaces are tap interfaces, they're still emulated ethernet... Wall of text incoming, various info... box#1: tap1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr fe:e1:ba:d1:be:f3 index 7 priority 0 llprio 3 groups: tap status: active inet 172.20.230.72 netmask 0xfffe box#2: tap1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr fe:e1:ba:d1:cf:92 index 7 priority 0 llprio 3 groups: tap status: active inet 172.20.230.73 netmask 0xfffe All is fine after starting ospfd, but as soon as I start bgpd, box#2 shows the following: Host Ethernet AddressNetif Expire Flags 172.20.230.7200:00:00:00:20:12 ? 12m30s # route -n get 172.20.230.72 route to: 172.20.230.72 destination: 172.20.230.72 mask: 255.255.255.255 interface: tap1 if address: 172.20.230.73 priority: 3 () flags: <UP,HOST,DONE,LLINFO,CLONED,CACHED> use mtuexpire 20 0 702 flags destination gateway lpref med aspath origin IS*> 172.20.230.72/31 172.20.230.64 200 0 i .64 is the loopback on one of its connected boxes that doesn't have broken entries tcpdump looks ok, afterwards: 19:14:23.723876 arp who-has 172.20.230.72 tell 172.20.230.73 19:14:23.901883 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3 19:14:24.022948 arp who-has 172.20.230.72 tell 172.20.230.73 19:14:24.201095 arp reply 172.20.230.72 is-at fe:e1:ba:d1:be:f3 but the correct entry is never installed, after I delete the broken arp entry it never readds a new one. This only happens with redist connected as far as I can tell, but bgpd probably shouldn't be able to mangle arp entries and prevent the correct one being added. If someone thinks they can diag/fix it then hit me up off-list and I can fire over ssh details. Thanks
Re: Raspberry Pi 3 booting from USB
I was stuck at that point for a while. Make sure you have everything you need to boot on the DOS partition of your USB drive; mine was missing u-boot.bin. Are you using the bootcode.bin and start.elf files from Raspbian? On March 5, 2017 9:25:59 AM EST, Otto Moerbeekwrote: >On Mon, Mar 06, 2017 at 12:36:55AM +1100, Jonathan Gray wrote: > >> The arm64 miniroot and bsd.rd already include fixup.dat and dtbs >> from https://github.com/raspberrypi/firmware/tree/master/boot >> >> There is no need to manually change them. > >I managed to get usb booting to work on a external powered device, bus >powered so far is not working for me. > >Also, I need to keep the sd card in, I might have done something >wrong with the setting of the vars. If I leave the sd card out nothing >happens on power up. > >By telling u-boot to prefer usb0 over mmc0 I got usb booting to work: > >setenv boot_targets usb0 mmc0 pxe dhcp >saveenv > > -Otto -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Raspberry Pi 3 booting from USB
In the case of my admittedly Frankensteined system, it was needed. The files from Raspbian were different. I will do a clean install when the next snap comes out with the latest firmware, DTBs, etc. Do you know why u-boot.bin didn't make it to my USB drive during installation and had to be manually added? Thanks, On March 5, 2017 8:36:55 AM EST, Jonathan Gray <j...@jsg.id.au> wrote: >The arm64 miniroot and bsd.rd already include fixup.dat and dtbs >from https://github.com/raspberrypi/firmware/tree/master/boot > >There is no need to manually change them. > >On Sun, Mar 05, 2017 at 08:21:56AM -0500, Joe Gidi wrote: >> >From further tinkering, I discovered that my Pi was only recognizing >128 MB of >> RAM until I switched to using the DTB and fixup.dat files from >Raspbian. Seems >> that those /boot/ files should be kept in sync. >> >> Thanks for all your work on this new platform! >> >> On March 5, 2017 3:36:16 AM EST, Jonathan Gray <j...@jsg.id.au> wrote: >> >On Sun, Mar 05, 2017 at 09:23:13AM +0100, Otto Moerbeek wrote: >> >> On Sun, Mar 05, 2017 at 07:00:46PM +1100, Jonathan Gray wrote: >> >> >> >> > On Sun, Mar 05, 2017 at 08:37:30AM +0100, Otto Moerbeek wrote: >> >> > > On Sat, Mar 04, 2017 at 06:40:57PM -0500, Joe Gidi wrote: >> >> > > >> >> > > > After jsg@ mentioned that booting a Raspberry Pi 3 from a >USB >> >device >> >> > > > might be >> >> > > > possible, I decided to find out how deep the rabbit hole is. >> >> > > > As it turns out, >> >> > > > it's currently a bit convoluted, but it can be made >> >> > > > to work with OpenBSD. >> >> > > > First off, USB boot support is just now getting fully ironed >> >out. >> >> > > > You'll need >> >> > > > to update the firmware on your Pi to make it work. I >> >> > > > installed the latest >> >> > > > (2017-03-02) Raspbian image to an SD card and >> >> > > > booted the Pi from that. While >> >> > > > booted in Raspbian, update the >> >> > > > firmware: >> >> > > > >> >> > > > sudo apt-get update >> >> > > > sudo apt-get >> >> > > > install rpi-update >> >> > > > sudo rpi-update >> >> > > > >> >> > > > It's then necessary to actually enable USB >> >> > > > boot support. Add the >> >> > > > following 2 lines to /boot/config.txt to enable USB boot >> >> > > > mode and set >> >> > > > a 5-second timeout to allow time for USB device >initialization: >> >> > > > program_usb_boot_mode=1 >> >> > > > program_usb_boot_timeout=1 >> >> > > > >> >> > > > NOTE: Apparently these >> >> > > > variables are set in the Pi's OTP memory, which >> >> > > > means once they're set, they >> >> > > > can't ever be unset. >> >> > > > >> >> > > > Reboot for the changes to take effect. At this point the >> >> > > > Pi should be >> >> > > > ready to support USB booting. >> >> > > > >> >> > > > While you still have a working >> >> > > > Raspbian install, grab a copy of the >> >> > > > /boot/bootcode.bin and /boot/start.elf >> >> > > > files for later use; apparently >> >> > > > we need these special versions of those two >> >> > > > files for USB boot >> >> > > > support. At this point we're done with Raspbian and can >> >> > > > shut it down >> >> > > > to install OpenBSD. >> >> > > > >> >> > > > Next, write the OpenBSD miniroot60.fs to an >> >> > > > SD card, plug in your USB >> >> > > > drive, and boot the Pi. You should be greeted with >> >> > > > the usual OpenBSD >> >> > > > installer, and you should be able to install to your USB >> >> > > > drive >> >> > > > (probably sd0). Once the installer is done, run 'halt', >unplug >> >the Pi, >> >> > > > and remove the SD card and USB drive. >> >> > > > >> >> >
Re: Raspberry Pi 3 booting from USB
>From further tinkering, I discovered that my Pi was only recognizing 128 MB of RAM until I switched to using the DTB and fixup.dat files from Raspbian. Seems that those /boot/ files should be kept in sync. Thanks for all your work on this new platform! On March 5, 2017 3:36:16 AM EST, Jonathan Gray <j...@jsg.id.au> wrote: >On Sun, Mar 05, 2017 at 09:23:13AM +0100, Otto Moerbeek wrote: >> On Sun, Mar 05, 2017 at 07:00:46PM +1100, Jonathan Gray wrote: >> >> > On Sun, Mar 05, 2017 at 08:37:30AM +0100, Otto Moerbeek wrote: >> > > On Sat, Mar 04, 2017 at 06:40:57PM -0500, Joe Gidi wrote: >> > > >> > > > After jsg@ mentioned that booting a Raspberry Pi 3 from a USB >device >> > > > might be >> > > > possible, I decided to find out how deep the rabbit hole is. >> > > > As it turns out, >> > > > it's currently a bit convoluted, but it can be made >> > > > to work with OpenBSD. >> > > > First off, USB boot support is just now getting fully ironed >out. >> > > > You'll need >> > > > to update the firmware on your Pi to make it work. I >> > > > installed the latest >> > > > (2017-03-02) Raspbian image to an SD card and >> > > > booted the Pi from that. While >> > > > booted in Raspbian, update the >> > > > firmware: >> > > > >> > > > sudo apt-get update >> > > > sudo apt-get >> > > > install rpi-update >> > > > sudo rpi-update >> > > > >> > > > It's then necessary to actually enable USB >> > > > boot support. Add the >> > > > following 2 lines to /boot/config.txt to enable USB boot >> > > > mode and set >> > > > a 5-second timeout to allow time for USB device initialization: >> > > > program_usb_boot_mode=1 >> > > > program_usb_boot_timeout=1 >> > > > >> > > > NOTE: Apparently these >> > > > variables are set in the Pi's OTP memory, which >> > > > means once they're set, they >> > > > can't ever be unset. >> > > > >> > > > Reboot for the changes to take effect. At this point the >> > > > Pi should be >> > > > ready to support USB booting. >> > > > >> > > > While you still have a working >> > > > Raspbian install, grab a copy of the >> > > > /boot/bootcode.bin and /boot/start.elf >> > > > files for later use; apparently >> > > > we need these special versions of those two >> > > > files for USB boot >> > > > support. At this point we're done with Raspbian and can >> > > > shut it down >> > > > to install OpenBSD. >> > > > >> > > > Next, write the OpenBSD miniroot60.fs to an >> > > > SD card, plug in your USB >> > > > drive, and boot the Pi. You should be greeted with >> > > > the usual OpenBSD >> > > > installer, and you should be able to install to your USB >> > > > drive >> > > > (probably sd0). Once the installer is done, run 'halt', unplug >the Pi, >> > > > and remove the SD card and USB drive. >> > > > >> > > > To make your USB drive bootable, you'll >> > > > need to plug it into another >> > > > system and mount its 'i' partition (the FAT32 >> > > > boot partition) to make >> > > > a few changes. Replace the bootcode.bin and start.elf >> > > > files with the >> > > > ones from Raspbian, and add the u-boot.bin file from the 'i' >> > > > partition >> > > > of your miniroot60.fs SD card. >> > > > >> > > > With those changes made, your Pi >> > > > should be able to boot OpenBSD >> > > > directly from a USB drive with no SD card >> > > > needed. Note that it seems >> > > > to take around 10 seconds for the Pi to reach the >> > > > OpenBSD bootloader >> > > > and fire up the kernel. >> > > > >> > > > Hope this information is helpful >> > > > to someone... >> > > > >> > > > -- >> > > > Joe Gidi >> > > > j...@entropicblur.com >> > > > >> > > > "You cannot buy skill." >> > > > -- Ross Seyfried >
Re: Raspberry Pi 3 booting from USB
Wow, apologies for the horrible line breaks inserted by this mail client... -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried - Original Message ----- From: "Joe Gidi" <j...@entropicblur.com> To: misc@openbsd.org Cc: Sent: Sat, 04 Mar 2017 18:40:57 -0500 Subject: Raspberry Pi 3 booting from USB After jsg@ mentioned that booting a Raspberry Pi 3 from a USB device might be possible, I decided to find out how deep the rabbit hole is. As it turns out, it's currently a bit convoluted, but it can be made to work with OpenBSD. First off, USB boot support is just now getting fully ironed out. You'll need to update the firmware on your Pi to make it work. I installed the latest (2017-03-02) Raspbian image to an SD card and booted the Pi from that. While booted in Raspbian, update the firmware: sudo apt-get update sudo apt-get install rpi-update sudo rpi-update It's then necessary to actually enable USB boot support. Add the following 2 lines to /boot/config.txt to enable USB boot mode and set a 5-second timeout to allow time for USB device initialization: program_usb_boot_mode=1 program_usb_boot_timeout=1 NOTE: Apparently these variables are set in the Pi's OTP memory, which means once they're set, they can't ever be unset. Reboot for the changes to take effect. At this point the Pi should be ready to support USB booting. While you still have a working Raspbian install, grab a copy of the /boot/bootcode.bin and /boot/start.elf files for later use; apparently we need these special versions of those two files for USB boot support. At this point we're done with Raspbian and can shut it down to install OpenBSD. Next, write the OpenBSD miniroot60.fs to an SD card, plug in your USB drive, and boot the Pi. You should be greeted with the usual OpenBSD installer, and you should be able to install to your USB drive (probably sd0). Once the installer is done, run 'halt', unplug the Pi, and remove the SD card and USB drive. To make your USB drive bootable, you'll need to plug it into another system and mount its 'i' partition (the FAT32 boot partition) to make a few changes. Replace the bootcode.bin and start.elf files with the ones from Raspbian, and add the u-boot.bin file from the 'i' partition of your miniroot60.fs SD card. With those changes made, your Pi should be able to boot OpenBSD directly from a USB drive with no SD card needed. Note that it seems to take around 10 seconds for the Pi to reach the OpenBSD bootloader and fire up the kernel. Hope this information is helpful to someone... -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
Raspberry Pi 3 booting from USB
After jsg@ mentioned that booting a Raspberry Pi 3 from a USB device might be possible, I decided to find out how deep the rabbit hole is. As it turns out, it's currently a bit convoluted, but it can be made to work with OpenBSD. First off, USB boot support is just now getting fully ironed out. You'll need to update the firmware on your Pi to make it work. I installed the latest (2017-03-02) Raspbian image to an SD card and booted the Pi from that. While booted in Raspbian, update the firmware: sudo apt-get update sudo apt-get install rpi-update sudo rpi-update It's then necessary to actually enable USB boot support. Add the following 2 lines to /boot/config.txt to enable USB boot mode and set a 5-second timeout to allow time for USB device initialization: program_usb_boot_mode=1 program_usb_boot_timeout=1 NOTE: Apparently these variables are set in the Pi's OTP memory, which means once they're set, they can't ever be unset. Reboot for the changes to take effect. At this point the Pi should be ready to support USB booting. While you still have a working Raspbian install, grab a copy of the /boot/bootcode.bin and /boot/start.elf files for later use; apparently we need these special versions of those two files for USB boot support. At this point we're done with Raspbian and can shut it down to install OpenBSD. Next, write the OpenBSD miniroot60.fs to an SD card, plug in your USB drive, and boot the Pi. You should be greeted with the usual OpenBSD installer, and you should be able to install to your USB drive (probably sd0). Once the installer is done, run 'halt', unplug the Pi, and remove the SD card and USB drive. To make your USB drive bootable, you'll need to plug it into another system and mount its 'i' partition (the FAT32 boot partition) to make a few changes. Replace the bootcode.bin and start.elf files with the ones from Raspbian, and add the u-boot.bin file from the 'i' partition of your miniroot60.fs SD card. With those changes made, your Pi should be able to boot OpenBSD directly from a USB drive with no SD card needed. Note that it seems to take around 10 seconds for the Pi to reach the OpenBSD bootloader and fire up the kernel. Hope this information is helpful to someone... -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
arm64 Raspberry Pi 3 - no disks available?
I know the arm64 port is still in its early days and under heavy development, but I'm trying to install the most recent available snapshot and running into a problem. I wrote the miniroot60.fs to an SD card and powered up the system. Serial console works fine, and the installer functions as usual, up until: Available disks are: none. Which disk is the root disk? ('?' for details) Indeed, dmesg shows no sd devices, even though it just booted from sd0: OpenBSD 6.0-current (RAMDISK) #0: Tue Feb 28 15:58:10 AEDT 2017    j...@arm64.jsg.id.au:/usr/src/sys/arch/arm64/compile/RAMDISK real mem = 989855744 (944MB) avail mem = 928395264 (885MB) mainbus0 at root: Raspberry Pi 3 Model B Rev 1.2 simplebus0 at mainbus0: "soc" bcmintc0 at simplebus0 bcmdog0 at simplebus0 pluart0 at simplebus0 com0 at simplebus0: ns16550, no working fifo com0: console dwctwo0 at simplebus0 agtimer0 at simplebus0: tick rate 19200 KHz simplebus1 at mainbus0: "clocks" usb0 at dwctwo0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Broadcom DWC2 root hub" rev 2.00/1.00 addr 1 uhub1 at uhub0 port 1 configuration 1 interface 0 "Standard Microsystems product 0x9514" rev 2.00/2.00 addr 2 smsc0 at uhub1 port 1 configuration 1 interface 0 "Standard Microsystems SMSC9512/14" rev 2.00/2.00 addr 3 smsc0: address b8:27:eb:02:4e:20 ukphy0 at smsc0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x0001f0, model 0x000c bootfile: sd0a:/bsd boot device: lookup sd0a:/bsd failed WARNING: CHECK AND RESET THE DATE! Is this expected at this point? Should I be trying to install to another device, like a USB hard drive? Thanks for any hints. -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
What is the future of the multicast routing daemons in OpenBSD?
I am wondering about the future of the multicast routing daemons in base on OpenBSD -- is the future in mrouted(8), or dvmrpd(8), or something else? I am aware that dvmrpd(8) is the newer codebase -- but when I have tried to use it in practice I have had consistent problems with the daemon crashing under normal scenarios. In my most recent dvmrpd test scenario, I set net.inet.ip.mforwarding to 1, created the following dvmrpd.conf configuration file, ran the daemon in debug mode and then started the Windows version of the Sonos Controller application on, in this scenario, VLAN 3 (which immediately makes dvmrpd crash): # cat dvmrpd.conf group { interface vlan3 interface vlan5 } # dvmrpd -dvf /etc/dvmrpd.conf startup kmr_init: interface vlan5 kmr_init: interface vlan3 fsm_if: event 'UP' resulted in action 'START' and changing state for interface vlan5 from 'DOWN' to 'QUERIER' fsm_if: event 'UP' resulted in action 'START' and changing state for interface vlan3 from 'DOWN' to 'QUERIER' rt_insert: inserting route 10.82.5.0/24 rt_insert: inserting route 10.82.3.0/24 send_igmp_query: interface vlan5 send_igmp_query: interface vlan3 [... START SONOS CONTROLLER ON VLAN 3 ...] mfc_start_expire_timer: group 239.255.255.250 mfc_start_prune_timer: group 239.255.255.250 fatal in dvmrpe: unknown neighbor to send prune mrt_add_mfc: interface 13, group 239.255.255.250 fatal in rde: pipe closed fatal in parent: pipe closed Initially, the daemon _appears_ to be running fine, until I start the Sonos Controller application at the point indicated above, when the daemon immediately outputs the errors shown above and exits. The culprit packet that appears to cause dvmrpd to crash is a SSDP discovery packet sent by the Sonos Controller application to 239.255.255.250 (see below): tcpdump: listening on vlan3, link-type EN10MB 17:45:10.417081 10.82.3.1 > 224.0.0.1: igmp query [tos 0xc0] [ttl 1] (id 23931, len 28) 17:45:10.417103 10.82.3.1 > 224.0.0.4: igmp dvmrp Probe genid 2257873240 [tos 0xc0] [ttl 1] (id 35152, len 32) 17:45:19.248851 10.82.3.100 > 239.255.255.250: igmp nreport 239.255.255.250 [ttl 1] (id 31513, len 32, optlen=4 IPOPT-148{4}) 17:45:20.426728 10.82.3.1 > 224.0.0.4: igmp dvmrp Probe genid 2257873240 [tos 0xc0] [ttl 1] (id 41676, len 32) [... START SONOS CONTROLLER ON VLAN 3 ...] 17:45:25.376993 10.82.3.100.1901 > 239.255.255.250.1900: udp 230 (ttl 4, id 31514, len 258) I have had relatively more success with mrouted(8). It seems to work in most of the scenarios I have used it in, although in one case I have not been able to get it to work on one particular piece of hardware for no discernible reason -- no errors, no warnings found anywhere, it just fails to route multicast packets. mrouted(8) has a significant limitation though -- it only supports 32 VIFs on the entire system. If you have more than 32 virtual interfaces it will ignore the 33rd interface and beyond (the system decides the ordering of the interfaces). I can't use igmpproxy from ports because I require multiple "upstream" interfaces. I have been thinking about jumping into the code to try to address these issues, but I'm not sure where to direct my efforts. I am inclined to focus on the crash in dvmrpd -- but it's not clear from anything I have read that dvmrpd is the future of multicast routing in OpenBSD. I have briefly looked into the feasibility of increasing the number of VIFs supported by mrouted, and it looks like that may be non-trivial, and it seems even less likely that mrouted is the future of multicast routing on OpenBSD. I am also troubled by the no error, no warning failure of mrouted on the system I described above -- wouldn't even know where to start with that one. Thanks in advance for any advice on this subject... Joe Crivello
Re: Bizarre arp entry corruption
On 12/12/2016 10:27, Martin Pieuchot wrote: On 11/12/16(Sun) 00:50, Joe Holden wrote: On 10/12/2016 08:43, Mihai Popescu wrote: seeing some bizarre behaviour on one box, on one specific interface: Hello, This looks like some stupid TV game, where contesters are given some clues from time to time and they have to guess what is the real shit. Do post your FULL dmesg and configurations for network if you really want someone to even think at your issue. Isn't that obvious? Bye! Appreciate the useless response (but still better than nothing!), the affected box has since been reverted to older snapshot and thus no more debugging can be done - someone else will have to do it. I'd appreciate to see the output of 'netstat -rnf inet' when it is relevant. Without that information it's hard to understand. But there's a bug somewhere, it has to be fixed. Not that dmesg is even relevant since it is a userland bug not a kernel problem but anyway: It's a kernel problem. I'll see if I can recreate it but I'm not holding my breath - it only breaks once BGP loaded the table which leads me to thing it is actually bgpd that is updating the llinfo with bogus info and even though I have a feed in my lab it doesn't do the same thing.
Re: Bizarre arp entry corruption
On 10/12/2016 08:43, Mihai Popescu wrote: seeing some bizarre behaviour on one box, on one specific interface: Hello, This looks like some stupid TV game, where contesters are given some clues from time to time and they have to guess what is the real shit. Do post your FULL dmesg and configurations for network if you really want someone to even think at your issue. Isn't that obvious? Bye! Appreciate the useless response (but still better than nothing!), the affected box has since been reverted to older snapshot and thus no more debugging can be done - someone else will have to do it. Not that dmesg is even relevant since it is a userland bug not a kernel problem but anyway: OpenBSD 6.0-current (GENERIC.MP) #19: Wed Dec 7 12:07:13 MST 2016 bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4273471488 (4075MB) avail mem = 4139397120 (3947MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9d000 (74 entries) bios0: vendor American Megatrends Inc. version "1ADQW068" date 11/16/2010 bios0: Sun Microsystems SUN FIRE X4150 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S5 acpi0: tables DSDT FACP APIC SPCR MCFG SSDT OEMB HPET EINJ BERT ERST HEST acpi0: wakeup devices SPE4(S1) SPE2(S1) SPE1(S1) P8PC(S1) P0P1(S1) UAR1(S1) P0P5(S1) P0P6(S1) P0P7(S1) NPE4(S1) NPE5(S1) NPE6(S1) NPE7(S1) USB0(S1) USB1(S1) USB2(S1) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 4189.89 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,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE,LONG,LAHF,PERF,SENSOR cpu0: 6MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 332MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.51 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,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE,LONG,LAHF,PERF,SENSOR cpu1: 6MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.51 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE,LONG,LAHF,PERF,SENSOR cpu2: 6MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.52 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,XSAVE,LONG,LAHF,PERF,SENSOR cpu3: 6MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins ioapic1 at mainbus0: apid 5 pa 0xfec8, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (NPES) acpiprt2 at acpi0: bus 2 (SPE4) acpiprt3 at acpi0: bus -1 (SPE2) acpiprt4 at acpi0: bus 3 (SPE1) acpiprt5 at acpi0: bus 4 (P8PC) acpiprt6 at acpi0: bus 15 (P0P1) acpiprt7 at acpi0: bus -1 (P0P5) acpiprt8 at acpi0: bus -1 (P0P6) acpiprt9 at acpi0: bus -1 (P0P7) acpiprt10 at acpi0: bus 7 (NPE4) acpiprt11 at acpi0: bus 11 (NPE5) acpiprt12 at acpi0: bus 12 (NPE6) acpiprt13 at acpi0: bus 13 (NPE7) acpiprt14 at acpi0: bus 14 (P0P4) acpiprt15 at acpi0: bus -1 (BR1E) acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) acpicpu2 at acpi0: C1(@1 halt!) acpicpu3 at acpi0: C1(@1 halt!) "PNP0501" at acpi0 not configured "PNP0501" at acpi0 not configured acpibtn0 at acpi0: PWRB "IPI0001" at acpi0 not configured ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 5000P Host" rev 0xb1 ppb0 at pci0 dev 2 function 0 "Intel 5000 PCIE" rev 0xb1 pci1 at ppb0 bus 1 ppb1 at pci1 dev 0 function 0 "Intel 6321ESB PCIE" rev 0x01 pci2 at ppb1 bus 2 ppb2 at pci2 dev 0 function 0 "Intel 6321ESB PCIE" rev 0x01 pci3 at ppb2 bus 3 ppb3 at pci2 dev 2 function 0 "Intel 6321ESB PCIE" rev 0x01 pci4 at ppb3 bus 4 em0 at pci4 dev 0 function 0 "Intel 80003ES2" rev 0x01: msi, address 00:23:8b:57:b4:9e em1 at pci4 dev 0 function 1 "Intel 80003ES2" rev 0x01: msi, address 00:23:8b:57:b4:9f ppb4 at pci1 dev 0 function 3 "Intel 6321ESB PCIE-PCIX" rev 0x01 pci5 at ppb4 bus 5 ppb5 at pci0 dev 3 function 0 "Intel 5000 PCIE" rev 0xb1 pci6 at ppb5 bus
Re: Bizarre arp entry corruption
On 08/12/2016 14:35, Joe Holden wrote: On 08/12/2016 13:56, Joe Holden wrote: Hi guys, I've just updated a couple of boxes to the Dec 7th snapshot and I'm seeing some bizarre behaviour on one box, on one specific interface: The box in question is an OSPF and BGP speaker, and the following happens when booted: After OSPF and BGP tables load, a couple of minutes later the following appear: Dec 8 06:33:03 edge-pe-2 /bsd: arp_rtrequest: bad gateway value: em0 Dec 8 06:33:03 edge-pe-2 last message repeated 2 times Dec 8 06:33:04 edge-pe-2 /bsd: arpresolve: X.X.X.X: incorrect arp information Then some seconds later: Dec 8 06:41:41 edge-pe-2 /bsd: arpresolve: unresolved and rt_expire == 0 At this point the arp entry for the neighbour in question has been updated so that the lladdr is all zeros and the interface is simply '?' according to arp -n. The box it is paired with that has a pretty much identical config doesn't exhibit the same problem and this only occurs on the single em0 interface (the box has about 6 active in total, mix of em and ix). I should clarify that this isn't CARP, but rather the box it is directly connected to. OpenBSD 6.0-current (GENERIC.MP) #19: Wed Dec 7 12:07:13 MST 2016 bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP I don't see any odd behaviour on the wire, according to pcap the who-has and associated reply is seen once as expected with the correct lladdr, but at some point it gets overwritten with the above. Previous kernel was about 2 months old which leaves a large number of commits to check through - I can't see anything that might cause this from a quick look though so I was hoping someone might have an idea. For now i've had to add a static arp entry with permanent to prevent it misbehaving but that has stopped working at least once so far. I also have limited debug ability as the box is part of a live network and obviously it causes disruption, and I can't recreate it in a lab with identical configurations. Any pointers appreciated! Cheers Actually looks like it breaks when BGP comes up, a route -nvd get looks ok, but what else should I be checking? After it breaks it doesn't seem to want to do any arp resolution on the interface until it I do down/up...
Re: Bizarre arp entry corruption
On 08/12/2016 13:56, Joe Holden wrote: Hi guys, I've just updated a couple of boxes to the Dec 7th snapshot and I'm seeing some bizarre behaviour on one box, on one specific interface: The box in question is an OSPF and BGP speaker, and the following happens when booted: After OSPF and BGP tables load, a couple of minutes later the following appear: Dec 8 06:33:03 edge-pe-2 /bsd: arp_rtrequest: bad gateway value: em0 Dec 8 06:33:03 edge-pe-2 last message repeated 2 times Dec 8 06:33:04 edge-pe-2 /bsd: arpresolve: X.X.X.X: incorrect arp information Then some seconds later: Dec 8 06:41:41 edge-pe-2 /bsd: arpresolve: unresolved and rt_expire == 0 At this point the arp entry for the neighbour in question has been updated so that the lladdr is all zeros and the interface is simply '?' according to arp -n. The box it is paired with that has a pretty much identical config doesn't exhibit the same problem and this only occurs on the single em0 interface (the box has about 6 active in total, mix of em and ix). I should clarify that this isn't CARP, but rather the box it is directly connected to. OpenBSD 6.0-current (GENERIC.MP) #19: Wed Dec 7 12:07:13 MST 2016 bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP I don't see any odd behaviour on the wire, according to pcap the who-has and associated reply is seen once as expected with the correct lladdr, but at some point it gets overwritten with the above. Previous kernel was about 2 months old which leaves a large number of commits to check through - I can't see anything that might cause this from a quick look though so I was hoping someone might have an idea. For now i've had to add a static arp entry with permanent to prevent it misbehaving but that has stopped working at least once so far. I also have limited debug ability as the box is part of a live network and obviously it causes disruption, and I can't recreate it in a lab with identical configurations. Any pointers appreciated! Cheers
Bizarre arp entry corruption
Hi guys, I've just updated a couple of boxes to the Dec 7th snapshot and I'm seeing some bizarre behaviour on one box, on one specific interface: The box in question is an OSPF and BGP speaker, and the following happens when booted: After OSPF and BGP tables load, a couple of minutes later the following appear: Dec 8 06:33:03 edge-pe-2 /bsd: arp_rtrequest: bad gateway value: em0 Dec 8 06:33:03 edge-pe-2 last message repeated 2 times Dec 8 06:33:04 edge-pe-2 /bsd: arpresolve: X.X.X.X: incorrect arp information Then some seconds later: Dec 8 06:41:41 edge-pe-2 /bsd: arpresolve: unresolved and rt_expire == 0 At this point the arp entry for the neighbour in question has been updated so that the lladdr is all zeros and the interface is simply '?' according to arp -n. The box it is paired with that has a pretty much identical config doesn't exhibit the same problem and this only occurs on the single em0 interface (the box has about 6 active in total, mix of em and ix). OpenBSD 6.0-current (GENERIC.MP) #19: Wed Dec 7 12:07:13 MST 2016 bu...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP I don't see any odd behaviour on the wire, according to pcap the who-has and associated reply is seen once as expected with the correct lladdr, but at some point it gets overwritten with the above. Previous kernel was about 2 months old which leaves a large number of commits to check through - I can't see anything that might cause this from a quick look though so I was hoping someone might have an idea. For now i've had to add a static arp entry with permanent to prevent it misbehaving but that has stopped working at least once so far. I also have limited debug ability as the box is part of a live network and obviously it causes disruption, and I can't recreate it in a lab with identical configurations. Any pointers appreciated! Cheers
Re: High loadavg on recent snapshots?
On 02/12/2016 12:45, Otto Moerbeek wrote: On Fri, Dec 02, 2016 at 09:55:23AM +, Joe Holden wrote: Hi guys, Is anyone else seeing abnormally high load averages on recent snapshots? Seeing load reported as ~1 on idle machines (both VM and physical, amd64 and octeon): 9:48AM up 34 mins, 1 user, load averages: 1.21, 1.13, 1.01 (octeon snapshot as of 30th Nov) This is known and due to a different way some kernel threads operate. Maybe a bit unexpected, but not harmful, the processor(s) as seen in top(1) should be idle most if the time. -Otto Yeah - not concerned just a huge increase in idle average that doesn't correlate to any activity compared to snapshots from a week or so ago Another example on KVM guest: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 1 0.0 0.1 416 496 ?? Is 6:54PM0:01.23 /sbin/init root 50624 0.0 0.1 632 536 ?? Is 6:55PM0:00.38 dhclient: vio2 [priv] (dhclient) _dhcp42339 0.0 0.1 736 696 ?? Isp6:55PM0:00.19 dhclient: vio2 (dhclient) root 26736 0.0 0.4 364 1976 ?? Isp6:55PM0:00.27 syslogd: [priv] (syslogd) _syslogd 7398 0.0 0.3 968 1488 ?? Sp 6:55PM0:00.68 /usr/sbin/syslogd root 64373 0.0 0.3 872 1452 ?? Is 6:55PM0:00.12 /usr/sbin/sshd root 38751 0.0 0.2 676 1188 ?? Isp6:55PM0:00.35 /usr/sbin/cron root 80570 0.0 0.7 980 3396 ?? Ss 9:20PM0:54.17 sshd: root@ttyp0 (sshd) root 30271 0.0 0.1 612 744 p0 Ssp9:20PM0:00.34 -ksh (ksh) root 84509 0.0 0.1 356 412 p0 R+p/0 4:03AM0:00.00 ps -auxw root 99508 0.0 0.1 608 736 00 Is+p 6:55PM0:02.80 -ksh (ksh) 4:03AM up 9:09, 2 users, load averages: 1.26, 1.18, 1.11 (amd64 snapshot as of 27th Nov) Thanks
High loadavg on recent snapshots?
Hi guys, Is anyone else seeing abnormally high load averages on recent snapshots? Seeing load reported as ~1 on idle machines (both VM and physical, amd64 and octeon): 9:48AM up 34 mins, 1 user, load averages: 1.21, 1.13, 1.01 (octeon snapshot as of 30th Nov) Another example on KVM guest: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 1 0.0 0.1 416 496 ?? Is 6:54PM0:01.23 /sbin/init root 50624 0.0 0.1 632 536 ?? Is 6:55PM0:00.38 dhclient: vio2 [priv] (dhclient) _dhcp42339 0.0 0.1 736 696 ?? Isp6:55PM0:00.19 dhclient: vio2 (dhclient) root 26736 0.0 0.4 364 1976 ?? Isp6:55PM0:00.27 syslogd: [priv] (syslogd) _syslogd 7398 0.0 0.3 968 1488 ?? Sp 6:55PM0:00.68 /usr/sbin/syslogd root 64373 0.0 0.3 872 1452 ?? Is 6:55PM0:00.12 /usr/sbin/sshd root 38751 0.0 0.2 676 1188 ?? Isp6:55PM0:00.35 /usr/sbin/cron root 80570 0.0 0.7 980 3396 ?? Ss 9:20PM0:54.17 sshd: root@ttyp0 (sshd) root 30271 0.0 0.1 612 744 p0 Ssp9:20PM0:00.34 -ksh (ksh) root 84509 0.0 0.1 356 412 p0 R+p/0 4:03AM0:00.00 ps -auxw root 99508 0.0 0.1 608 736 00 Is+p 6:55PM0:02.80 -ksh (ksh) 4:03AM up 9:09, 2 users, load averages: 1.26, 1.18, 1.11 (amd64 snapshot as of 27th Nov) Thanks