Re: snapshots on artfiles.org mirror currently out of sync
On 6/3/22 10:11, Andreas Bartelt wrote: Hi, I've just noticed that at least the snapshots on the artfiles.org mirror haven't been updated since May, 15th. The mirror is still listed at PKG_PATH=https://mirror.hs-esslingen.de/pub/OpenBSD/snapshots/packages/amd64/ Best regards Andreas sorry, accidental copy/paste error in my last sentence -- what I wanted to write was: The mirror is still listed at https://www.openbsd.org/ftp.html
snapshots on artfiles.org mirror currently out of sync
Hi, I've just noticed that at least the snapshots on the artfiles.org mirror haven't been updated since May, 15th. The mirror is still listed at PKG_PATH=https://mirror.hs-esslingen.de/pub/OpenBSD/snapshots/packages/amd64/ Best regards Andreas
libssl/libtls signal the wrong signature algorithm in ServerKeyExchange message
In case an ECDSA based server certificate with ECDHE based key exchange is used, I've notice that the ServerKeyExchange message (always?) signals that this message has been signed with ecdsa-secp521r1-sha512 (0x0603) [tested on current with TLS 1.2 with P-256 as well as with P-521 server certificates -- the actual signature sizes differ as expected but the signalling of the signature algorithm is identical in both cases]. Example: in case the server certificate contains a P-256 based public key, the actually provided signature for the ServerKeyExchange message is ecdsa-secp256r1-sha256. However, the signature algorithm field signals 0x(0603) [ecdsa-secp521r1-sha512] instead of 0x(0403) [ecdsa-secp256r1-sha256]. Multiple TLS libraries seem to behave this way, but, according to RFCs, I would expect the actually used signature algorithm to be provided with the ServerKeyExchange message. Could someone please clarify if this is a bug? Slightly related: is there a good reason why libtls doesn't provide an API call for explicitly configuring allowed signature algorithms (via Signature Algorithms extension)? (e.g., in order to ensure that ecdsa-sha1 0x(0203) is not included in the list). Best regards Andreas
Re: gif(4) changes vs tunnelbroker
On 03/01/18 00:30, David Gwynne wrote: On 1 Mar 2018, at 02:22, Andreas Bartelt <o...@bartula.de> wrote: On 02/27/18 22:35, Pavel Korovin wrote: On 02/28, David Gwynne wrote: what is the status of sysctl net.inet.ipip ? David, thank you! That was easy :) Sorry for the noise. $ sysctl net.inet.ipip.allow net.inet.ipip.allow=0 # sysctl -w net.inet.ipip.allow=1 net.inet.ipip.allow: 0 -> 1 $ ping6 www.google.com PING www.google.com (2a00:1450:4013:c01::67): 56 data bytes 64 bytes from 2a00:1450:4013:c01::67: icmp_seq=0 hlim=48 time=40.500 ms 64 bytes from 2a00:1450:4013:c01::67: icmp_seq=1 hlim=48 time=40.645 ms ^C I'm also observing a breakage of a previously working IPv6 tunnelbroker config on current (problem introduced since at least Feb, 23rd). The combination of two things made it work again (or at least works around the underlying problem): 1) sysctl net.inet.ipip.allow=1 [not yet documented at www.openbsd.org/faq/current.html] 2) removing ``set state-policy if-bound'' from my pf.conf [which always worked before with the same tunnelbroker setup] According to pflog(4), a ping6 to some destination now looks buggy to me: - outgoing icmp6 echo request is only visible on gif(4) - incoming icmp6 echo reply is only visible on the underlying physical interface of gif(4) which blocks the ping6 in the case of ``set state-policy if-bound''. i found what i think is the problem. it turns out the net.inet.ipip.allow sysctl was a red herring. it controls the processing of ipip by the network stack, it is not related to whether gif should accept packets. the problem was i got the mapping of ip addresses in incoming packets to the addresses on the tunnels wrong. this should be fixed in src/sys/net/if_gif.c r1.112. yes, thanks -- it now works again with state-policy if-bound in pf.conf and net.inet.ipip.allow=0
Re: gif(4) changes vs tunnelbroker
On 02/27/18 22:35, Pavel Korovin wrote: On 02/28, David Gwynne wrote: what is the status of sysctl net.inet.ipip ? David, thank you! That was easy :) Sorry for the noise. $ sysctl net.inet.ipip.allow net.inet.ipip.allow=0 # sysctl -w net.inet.ipip.allow=1 net.inet.ipip.allow: 0 -> 1 $ ping6 www.google.com PING www.google.com (2a00:1450:4013:c01::67): 56 data bytes 64 bytes from 2a00:1450:4013:c01::67: icmp_seq=0 hlim=48 time=40.500 ms 64 bytes from 2a00:1450:4013:c01::67: icmp_seq=1 hlim=48 time=40.645 ms ^C I'm also observing a breakage of a previously working IPv6 tunnelbroker config on current (problem introduced since at least Feb, 23rd). The combination of two things made it work again (or at least works around the underlying problem): 1) sysctl net.inet.ipip.allow=1 [not yet documented at www.openbsd.org/faq/current.html] 2) removing ``set state-policy if-bound'' from my pf.conf [which always worked before with the same tunnelbroker setup] According to pflog(4), a ping6 to some destination now looks buggy to me: - outgoing icmp6 echo request is only visible on gif(4) - incoming icmp6 echo reply is only visible on the underlying physical interface of gif(4) which blocks the ping6 in the case of ``set state-policy if-bound''.
Re: Question about httpd tls config
On 08/15/17 09:54, Andreas Thulin wrote: Hi! I run httpd on 6.1-stable (thanks to all of you who make that possible!), with a pretty vanilla tls setup. When testing the server on ssllabs.com, results say that TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA is considered weak. How should I interpret that information, as you see it? And shouldn't default cipher strengths be >= 128? I have probably misunderstood something, so any pointers in the right direction would be lovely. Link to my test result: https://www.ssllabs.com/ssltest/analyze.html?d=esoteric.andreasthulin.se at least httpd on current doesn't include any 3DES cipher suites by default. I am also not aware of any TLS clients which are TLS 1.2-only and would prefer any 3DES cipher suite at the same time. In case your server is not required to be interoperable with some very old TLS 1.0-based legacy clients, you should simply exclude 3DES cipher suites. From a security perspective, although probably still sufficient for the foreseeable future, the 112-bit security level of 3DES looks like the weakest link in your specific setup. However, the much bigger problem is 3DES's 64-bit block length which is inherently prone to collisions (so-called SWEET32 attack). In order to mitigate this problem, the upcoming recommendation from NIST is to frequently change the key (every 2^20 64-bit data blocks -- see http://csrc.nist.gov/publications/drafts/800-67r2/sp800-67r2-draft.pdf ). In the context of libssl, BIO_set_ssl_renegotiate_bytes() (see BIO_f_ssl(3)) seems to be intended for this purpose. However, it doesn't seem to be called anywhere in OpenBSD's src repository. In case any developer is reading this -- does libssl/libtls/httpd somehow ensure that session keys will be refreshed after a cipher suite's maximum key lifetime (or, alternatively, the session gets terminated)? Although the recommended limit on the number of TLS records, which could be handled with the same session key, is much higher for AES-GCM (i.e., 2^32 records), there still is a limit. Best regards Andreas
Re: iwm performance
On 07/24/16 15:28, Stefan Sperling wrote: > On Sun, Jul 24, 2016 at 01:09:26PM +0200, Andreas Bartelt wrote: >> However, the wireless link via iwm(4) is currently almost unusable. >> Overall throughput for multiple tcp connections typically between 0 and >> 1 Mbit/s but mostly on the lower end, i.e., 0. > > Looking at the wifi environment you're testing this in is very important. > > Does this happen consistently, and everywhere? > Or only at your home, with something like 20 other wifi networks on > the same channel? > I've attached some scans regarding WiFi networks at my vicinity. I also did some measurements for iwn(4) regarding throughput at different locations. Performance was particularly bad after suspend/resume -- do you think this might be related? Best regards Andreas WiFi networks from scans very near at my access point (nwid's sanitized) [iwm(4) with observed througput between 1-11 Mbit/s; after suspend/resume, performance was only between 1-5 Mbits/s]: nwid mywlan chan 8 bssid 74:de:2b:3b:02:65 79% 54M privacy,short_preamble,short_slottime,wpa2 nwid aa chan 11 bssid 08:95:2a:87:f0:75 25% HT-MCS15 privacy,short_slottime,radio_measurement,wpa2 nwid bb chan 11 bssid 0a:95:2a:87:f0:77 22% HT-MCS15 privacy,short_slottime,radio_measurement,wpa2,802.1x nwid cc chan 11 bssid 8c:04:ff:b9:29:02 22% HT-MCS15 privacy,short_slottime,radio_measurement,wpa2 nwid dd chan 11 bssid 00:03:c9:8b:ee:10 17% 54M privacy,short_slottime,wep nwid ee chan 2 bssid 00:12:bf:6d:51:3c 16% 54M privacy,short_preamble,short_slottime,wpa2 nwid ff chan 4 bssid 90:f6:52:2b:4a:54 14% HT-MCS15 privacy,short_preamble,short_slottime,wpa2 nwid gg chan 11 bssid f4:06:8d:84:8a:31 13% HT-MCS7 privacy,short_slottime,wpa2 nwid hh chan 1 bssid 88:03:55:be:42:2e 11% HT-MCS32 privacy,short_preamble,short_slottime,wpa2 nwid ii chan 1 bssid 2c:59:e5:ef:f3:fa 11% 54M privacy,short_preamble,short_slottime,wpa2 nwid jj chan 2 bssid 18:83:bf:7d:61:4b 10% HT-MCS32 privacy,short_slottime,wpa2 nwid kk chan 11 bssid 24:65:11:2b:35:e6 10% HT-MCS15 privacy,short_preamble,short_slottime,wpa2 nwid oo chan 1 bssid 84:9c:a6:3a:e2:46 10% HT-MCS15 privacy,short_slottime,wpa2 nwid ll chan 1 bssid 24:65:11:04:68:62 7% HT-MCS15 privacy,short_preamble,short_slottime,wpa2 nwid mm chan 6 bssid 7c:4f:b5:97:0f:22 5% HT-MCS32 privacy,short_slottime,wpa2 nwid nn chan 6 bssid 54:67:51:03:45:df 5% HT-MCS15 privacy,short_slottime,wpa2 >From the room where I typically observe the reported througput problems: [best case I've observed relatively stable througput around 9 Mbits; after suspend/resume, performance was only between 0-1 Mbits/s] nwid mywlan chan 8 bssid 74:de:2b:3b:02:65 46% 54M privacy,short_preamble,short_slottime,wpa2 nwid aa chan 11 bssid 08:95:2a:87:f0:75 41% HT-MCS15 privacy,short_slottime,radio_measurement,wpa2 nwid bb chan 11 bssid 0a:95:2a:87:f0:77 38% HT-MCS15 privacy,short_slottime,radio_measurement,wpa2,802.1x nwid ee chan 2 bssid 00:12:bf:6d:51:3c 23% 54M privacy,short_preamble,short_slottime,wpa2
Re: iwm performance
On 07/22/16 11:36, Stefan Sperling wrote: > On Thu, Jul 21, 2016 at 08:25:11PM +0200, Andreas Bartelt wrote: >> sorry, my response was not precise - the "fatal" error is gone now but the >> observed performance problems are still there. > ... > In the best iwm performance regression report I've received so far, the > reporter tracked the regression down to a particular commit (r1.86 if_iwm.c). > Backing out that commit restores performance to 5.9 levels for this user. > But this commit fixed an unrelated problem, which was that IPv6 autoconf and > ARP briefly stopped working in -current after we upgraded iwm's firmware. > I don't understand how this relates. It may involve invisible details handled > within the magic firmware, or it may be a driver bug, or prior performance > levels may have been a side effect of a real stability problem. In any case, > I won't back out this commit to restore performance for one user if backing > out that commit means that other known bugs will come back. > > More generally speaking, given that our 11n implementation is still in its > infancy, and doesn't yet use any of the new features which are supposed to > vastly increase throughput, it is premature to complain about performance. > For now, stability gets priority. > Please don't get me wrong, my mail was not meant to be a complaint at all. While tracking current (I think it was shortly before or after 5.9 had been released) I've been observing some serious stability problems with regard to wireless for some time -- not only regarding iwm(4) on a Lenovo x250 as wireless client but also on the hostap side (ral(4) obviously in 11g mode and also running on current). The hostap box crashed multiple times a day and had to be rebooted. These problems are gone now, i.e., both sides don't crash anymore. However, the wireless link via iwm(4) is currently almost unusable. Overall throughput for multiple tcp connections typically between 0 and 1 Mbit/s but mostly on the lower end, i.e., 0. The "fatal firmware error" problem doesn't seem to be resolved - it just doesn't occur at every boot (see attached dmesg from yesterday's current). The bad throughput seems to be independent from this error message. I could verify that an old x61s with wpi(4) currently performs considerably better (throughput in the same setting is more stable at about 175 Kbits/s). Consequently, the ral(4) interface in 11g hostap mode at least doesn't seem to be the primary problem. Nevertheless, I've also observed that the presence of the x250 laptop sometimes also kills throughput of other wireless clients (iphone, ipad etc) - so I'm not 100% sure, i.e., the problems could at least be partially related to ral(4) in 11g hostap mode. Btw, can you recommend a (commercial or open source) wireless access point which is known to work well with iwm(4) in 11n mode on current? Best regards Andreas OpenBSD 6.0 (GENERIC.MP) #0: Sat Jul 23 09:03:23 CEST 2016 a...@obsd.bartelt.name:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8277159936 (7893MB) avail mem = 8021778432 (7650MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (64 entries) bios0: vendor LENOVO version "N10ET38W (1.17 )" date 08/20/2015 bios0: LENOVO 20CMCTO1WW acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT UEFI MSDM BATB FPDT UEFI DMAR acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.28 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.15 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SM
Re: how would you troubleshoot your wifi?
sorry, my response was not precise - the "fatal" error is gone now but the observed performance problems are still there.
Re: how would you troubleshoot your wifi?
On 07/21/16 10:34, Stefan Sperling wrote: > On Thu, Jul 14, 2016 at 01:13:21PM +0800, Miles Keaton wrote: >> iwm0: hw rev 0x140, fw ver 25.228 (API ver 9), address 5b:51:4f:a1:16:d9 >> iwm0: fatal firmware error > > You got some answers already but they were all misleading. > I believe I've already fixed this bug. Please verify my assumption by > upgrading to -current now and letting me know if the problem persists. > (Run fw_update iwm before upgrading or iwm won't work during the upgrade!) > > I'm also observing this error and I'm experiencing massive problems with regard to wireless performance on current (compared to 5.9 at some point) - unfortunately, I've been observing these for some time now. My guess would be that its related to iwm(4) but it could potentially also be related to the ral(4) side which runs in 802.11g hostap mode on current. I didn't have any time in order to look into this deeper yet -- I also made some changes with regard to the position of my access point but this (at least now) seems to be completely unrelated to the observed problems. Sorry for being of no help atm with regard to reporting observed problems with current in a timely manner. Best regards Andreas OpenBSD 6.0 (GENERIC.MP) #0: Thu Jul 21 04:55:30 CEST 2016 a...@obsd.bartelt.name:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8277159936 (7893MB) avail mem = 8021778432 (7650MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (64 entries) bios0: vendor LENOVO version "N10ET38W (1.17 )" date 08/20/2015 bios0: LENOVO 20CMCTO1WW acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT UEFI MSDM BATB FPDT UEFI DMAR acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.28 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.15 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.15 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.15 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpicpu0 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148
Re: low power device
On 09/19/14 01:42, Steve Litt wrote: ... Very, very nice! Two questions: 1) Can I safely assume that the Realtek RTL8111E works well with OpenBSD? 2) Where's the best place to buy it if you live in the US? I saw this, which looks pretty good, given that they give you the enclosure (and I presume the heat spreader) and a wall wort: http://store.netgate.com/kit-APU1C4.aspx I've been looking for something like this for a long time. Thanks! is anybody else using this recent BIOS snapshot on the APU.1c: Build 9/8/2014 (beta, reduced spew level) The first re(4) interface isn't always recognized after reboot. I don't know if it's related to the BIOS update since I didn't play much with this board when I still had the BIOS beta from April flashed. I've seen this re0-related problem multiple times with an OpenBSD snapshot from April and also with a newer snapshot from September. The kernel sometimes also freezes at ehci0 (see attachment). So, at least my APU.1c device doesn't work reliably at all. I was thinking about getting one of these (hopefully low-power) Supermicro boards: Atom N2800-based: http://www.supermicro.com/products/motherboard/ATOM/X9/X9SCAA-L.cfm Atom S1260-based: http://www.supermicro.com/products/motherboard/ATOM/X9/X9SBAA-F.cfm http://www.supermicro.com/products/motherboard/ATOM/X9/X9SBAA.cfm Atom C2xxx-based: http://www.supermicro.com/products/motherboard/Atom/X10/A1SRi-2558F.cfm http://www.supermicro.com/products/motherboard/Atom/X10/A1SAi-2550F.cfm Celeron J1900-based: http://www.supermicro.com/products/motherboard/celeron/X10/X10SBA-L.cfm Does anybody have experience with one of the boards from above on OpenBSD? Best regards Andreas OpenBSD 5.6-current (GENERIC.MP) #372: Wed Sep 10 18:03:54 MDT 2014 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4246003712 (4049MB) avail mem = 4124246016 (3933MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (7 entries) bios0: vendor coreboot version 4.0 date 09/08/2014 bios0: PC Engines APU acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD G-T40E Processor, 1000.14 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 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 199MHz cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD G-T40E Processor, 1000.00 MHz 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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins acpiprt0 at acpi0: bus -1 (AGPB) acpiprt1 at acpi0: bus -1 (HDMI) acpiprt2 at acpi0: bus 1 (PBR4) acpiprt3 at acpi0: bus 2 (PBR5) acpiprt4 at acpi0: bus 3 (PBR6) acpiprt5 at acpi0: bus -1 (PBR7) acpiprt6 at acpi0: bus 5 (PE20) acpiprt7 at acpi0: bus -1 (PE21) acpiprt8 at acpi0: bus -1 (PE22) acpiprt9 at acpi0:
Re: low power device
On 09/19/14 17:35, Chris Cappuccio wrote: Andreas Bartelt [o...@bartula.de] wrote: is anybody else using this recent BIOS snapshot on the APU.1c: Build 9/8/2014 (beta, reduced spew level) The first re(4) interface isn't always recognized after reboot. I don't know if it's related to the BIOS update since I didn't play much with this board when I still had the BIOS beta from April flashed. I've seen this re0-related problem multiple times with an OpenBSD snapshot from April and also with a newer snapshot from September. The kernel sometimes also freezes at ehci0 (see attachment). So, at least my APU.1c device doesn't work reliably at all. I was thinking about getting one of these (hopefully low-power) Supermicro boards: Atom N2800-based: http://www.supermicro.com/products/motherboard/ATOM/X9/X9SCAA-L.cfm Atom S1260-based: http://www.supermicro.com/products/motherboard/ATOM/X9/X9SBAA-F.cfm http://www.supermicro.com/products/motherboard/ATOM/X9/X9SBAA.cfm Atom C2xxx-based: http://www.supermicro.com/products/motherboard/Atom/X10/A1SRi-2558F.cfm http://www.supermicro.com/products/motherboard/Atom/X10/A1SAi-2550F.cfm Celeron J1900-based: http://www.supermicro.com/products/motherboard/celeron/X10/X10SBA-L.cfm Does anybody have experience with one of the boards from above on OpenBSD? The X10SBA is a really nice board, although the C2550 based boards look nice too. Per watt, the C2550 and J1900 are very competitive with the higher end Intel CPUs. The X10SBA will be closer in price to the APU than the C2550 based boards! I've become afraid of UEFI BIOSes since legacy mode doesn't seem to work with all of them (i.e., ASUS P9D WS). Could you successfully boot a mainboard with one of the CPUs from above on OpenBSD? Did you measure power consumption at idle? I've never had problems with re0 and reboots on APU although you may be right about the newer BIOS being problematic (or you may have some flaky hardware?) You should try and re-flash the April bios. I can send it over if you need the image. I've just reflashed the 4/5/2014 version which is now called current production -- the same problem regarding re0. So yes, probably it's a flaky NIC. Taken together with the flaky mSATA drive of some APU.1c revisions and the unusually high operating temperature, I really can't recommend this device. On the other hand, there were a couple of positive reports regarding the APU.1c on misc@, so maybe I just had bad luck... Best regards Andreas
Re: Weird disklabel problem
On 05/03/14 20:22, Kenneth Westerback wrote: On 3 May 2014 10:13, Andreas Bartelt o...@bartula.de wrote: On 05/03/14 15:01, Kenneth Westerback wrote: On 3 May 2014 08:49, Andreas Bartelt o...@bartula.de wrote: On 05/03/14 14:10, Kenneth Westerback wrote: On 3 May 2014 06:27, Martijn Rijkeboer mart...@bunix.org wrote: So marking a partition as 'Active/Bootable', (the 00 - 80 change) causes your system to hang. Apparently Linux does this when you 'Label' it. The OpenBSD installer does it for you when you select 'Whole disk'. Nothing obviously to do with the disklabel. You could test this by manually setting the 'Active' flag on the working Linux MBR. Or, conversely unsetting the flag with fdisk after the OpenBSD install but before rebooting. In either case does it get further before noticing that it can't boot? I did some testing with the following results: 1. Partition disk with Linux gparted and use cfdisk to set partition type to A6 and OpenBSD disklabel to set disklabel. (partition: 0; start: 2048; size: 1953519616) - Bootflag off, no disklabel - boot - Bootflag on, no disklabel - boot - Bootflag off, with disklabel - freeze - Bootflag on, with disklabel - freeze 2. Partition disk with OpenBSD fdisk + disklabel (installer start + size). (partition: 3, start: 64; size: 1953520001) - Bootflag off, no disklabel - freeze - Bootflag on, no disklabel - freeze - Bootflag off, with disklabel - freeze - Bootflag on, with diskalbel - freeze 3. Partition disk with OpenBSD fdisk + disklabel (linux start + size). (partition: 3: start: 2048; size: 1953519616) - Bootflag off, no disklabel - boot - Bootflag on, no disklabel - boot - Bootflag off, with disklabel - freeze - Bootflag on, with disklabel - freeze 4. Partition disk with OpenBSD fdisk with type 83 (installer start + size). (partition: 3, start: 64; size: 1953520001) - Bootflag off - freeze - Bootflag on - freeze It looks like the motherboard doesn't like the partition to start at 64 and it also doesn't like disklabels. Any suggestions on what to try next or should I just buy a different motherboard? Kind regards, Martijn Rijkeboer Looking around I found that one of my machines has a gigabyte GA-Z87-D3HP board, and I scrounged up a 1TB WD 10EARS disk. The disk was from another machine and had a working OpenBSD system. Lo and behold, plugged it into the GA-Z87-D3HP board and the system hung in the POST. Put the disk back on the other system, dd'ed /dev/zero over the disklabel, moved it back and the system booted. How extremely interesting. And weird. Ken such problems also seem to occur on some ASUS boards -- but only when SATA drives are used. OpenBSD did boot fine from a USB stick: http://marc.info/?l=openbsd-miscm=137862502730004w=2 Best Regards Andreas Indeed. Experiments here show that plugging in a pci - sata card to avoid the Intel SATA chip makes the disk work fine. Disks smaller than 1TB also work. So I'm guessing it's something magical about 4K-sector disks presenting themselves as 512-byte sector disks that is the source of problems. I'm still a bit fogged as to how a disklabel triggers the problem. I also saw these problems with a Chronos MKNSSDCR120GB SSD drive. I don't know which sector size these drives use internally... Actually, I didn't get any of my drives to work with OpenBSD on this mainboard. I don't know if it helps -- I've also unsuccessfully tested a 320GB WD3200AAKS from 08/2010. Best Regards Andreas OK, I got it booting. In a fairly useless config, but ... Booting from a -current amd64 cd55.iso cd-rom, I (E)dited the MBR so that the OpenBSD 'A6' partition started on sector 2048, and was 500MB in size. I accepted the auto configured disklabel (i.e. all space in 'a') and installed w/o X, Compiler or games sets. Removing the CD and rebooting got me to the usual login prompt. I'm going to experiment some more, but I'm now suspicious that the old '512MB' limit is coming into play somehow. So for those following along, try a tiny OpenBSD MBR partition starting at sector 2048 and see what happens. And of course if it works, how big can your partition be before it stops working. I've just tried this -- starting the A6 partition (partition 3) at sector 2048 prevented POST from freezing. However, the system didn't boot in my case. Afterwards, I did the same manual partitioning setup (A6, partition 3, 500m, flagged as bootable), but with starting sector 64 instead, which resulted in POST freezing again. Best Regards Andreas
Re: Weird disklabel problem
On 05/03/14 14:10, Kenneth Westerback wrote: On 3 May 2014 06:27, Martijn Rijkeboer mart...@bunix.org wrote: So marking a partition as 'Active/Bootable', (the 00 - 80 change) causes your system to hang. Apparently Linux does this when you 'Label' it. The OpenBSD installer does it for you when you select 'Whole disk'. Nothing obviously to do with the disklabel. You could test this by manually setting the 'Active' flag on the working Linux MBR. Or, conversely unsetting the flag with fdisk after the OpenBSD install but before rebooting. In either case does it get further before noticing that it can't boot? I did some testing with the following results: 1. Partition disk with Linux gparted and use cfdisk to set partition type to A6 and OpenBSD disklabel to set disklabel. (partition: 0; start: 2048; size: 1953519616) - Bootflag off, no disklabel - boot - Bootflag on, no disklabel - boot - Bootflag off, with disklabel - freeze - Bootflag on, with disklabel - freeze 2. Partition disk with OpenBSD fdisk + disklabel (installer start + size). (partition: 3, start: 64; size: 1953520001) - Bootflag off, no disklabel - freeze - Bootflag on, no disklabel - freeze - Bootflag off, with disklabel - freeze - Bootflag on, with diskalbel - freeze 3. Partition disk with OpenBSD fdisk + disklabel (linux start + size). (partition: 3: start: 2048; size: 1953519616) - Bootflag off, no disklabel - boot - Bootflag on, no disklabel - boot - Bootflag off, with disklabel - freeze - Bootflag on, with disklabel - freeze 4. Partition disk with OpenBSD fdisk with type 83 (installer start + size). (partition: 3, start: 64; size: 1953520001) - Bootflag off - freeze - Bootflag on - freeze It looks like the motherboard doesn't like the partition to start at 64 and it also doesn't like disklabels. Any suggestions on what to try next or should I just buy a different motherboard? Kind regards, Martijn Rijkeboer Looking around I found that one of my machines has a gigabyte GA-Z87-D3HP board, and I scrounged up a 1TB WD 10EARS disk. The disk was from another machine and had a working OpenBSD system. Lo and behold, plugged it into the GA-Z87-D3HP board and the system hung in the POST. Put the disk back on the other system, dd'ed /dev/zero over the disklabel, moved it back and the system booted. How extremely interesting. And weird. Ken such problems also seem to occur on some ASUS boards -- but only when SATA drives are used. OpenBSD did boot fine from a USB stick: http://marc.info/?l=openbsd-miscm=137862502730004w=2 Best Regards Andreas
Re: Weird disklabel problem
On 05/03/14 15:01, Kenneth Westerback wrote: On 3 May 2014 08:49, Andreas Bartelt o...@bartula.de wrote: On 05/03/14 14:10, Kenneth Westerback wrote: On 3 May 2014 06:27, Martijn Rijkeboer mart...@bunix.org wrote: So marking a partition as 'Active/Bootable', (the 00 - 80 change) causes your system to hang. Apparently Linux does this when you 'Label' it. The OpenBSD installer does it for you when you select 'Whole disk'. Nothing obviously to do with the disklabel. You could test this by manually setting the 'Active' flag on the working Linux MBR. Or, conversely unsetting the flag with fdisk after the OpenBSD install but before rebooting. In either case does it get further before noticing that it can't boot? I did some testing with the following results: 1. Partition disk with Linux gparted and use cfdisk to set partition type to A6 and OpenBSD disklabel to set disklabel. (partition: 0; start: 2048; size: 1953519616) - Bootflag off, no disklabel - boot - Bootflag on, no disklabel - boot - Bootflag off, with disklabel - freeze - Bootflag on, with disklabel - freeze 2. Partition disk with OpenBSD fdisk + disklabel (installer start + size). (partition: 3, start: 64; size: 1953520001) - Bootflag off, no disklabel - freeze - Bootflag on, no disklabel - freeze - Bootflag off, with disklabel - freeze - Bootflag on, with diskalbel - freeze 3. Partition disk with OpenBSD fdisk + disklabel (linux start + size). (partition: 3: start: 2048; size: 1953519616) - Bootflag off, no disklabel - boot - Bootflag on, no disklabel - boot - Bootflag off, with disklabel - freeze - Bootflag on, with disklabel - freeze 4. Partition disk with OpenBSD fdisk with type 83 (installer start + size). (partition: 3, start: 64; size: 1953520001) - Bootflag off - freeze - Bootflag on - freeze It looks like the motherboard doesn't like the partition to start at 64 and it also doesn't like disklabels. Any suggestions on what to try next or should I just buy a different motherboard? Kind regards, Martijn Rijkeboer Looking around I found that one of my machines has a gigabyte GA-Z87-D3HP board, and I scrounged up a 1TB WD 10EARS disk. The disk was from another machine and had a working OpenBSD system. Lo and behold, plugged it into the GA-Z87-D3HP board and the system hung in the POST. Put the disk back on the other system, dd'ed /dev/zero over the disklabel, moved it back and the system booted. How extremely interesting. And weird. Ken such problems also seem to occur on some ASUS boards -- but only when SATA drives are used. OpenBSD did boot fine from a USB stick: http://marc.info/?l=openbsd-miscm=137862502730004w=2 Best Regards Andreas Indeed. Experiments here show that plugging in a pci - sata card to avoid the Intel SATA chip makes the disk work fine. Disks smaller than 1TB also work. So I'm guessing it's something magical about 4K-sector disks presenting themselves as 512-byte sector disks that is the source of problems. I'm still a bit fogged as to how a disklabel triggers the problem. I also saw these problems with a Chronos MKNSSDCR120GB SSD drive. I don't know which sector size these drives use internally... Actually, I didn't get any of my drives to work with OpenBSD on this mainboard. I don't know if it helps -- I've also unsuccessfully tested a 320GB WD3200AAKS from 08/2010. Best Regards Andreas
Problems with ASUS P9D WS (socket 1150, Haswell Xeon E3-1230V3)
Hi, I have problems booting OpenBSD from SATA hard drives with the ASUS P9D WS mainboard. I've successfully verified that OpenBSD can boot with this mainboard since booting OpenBSD works without problems via USB (see dmesg). However, OpenBSD doesn't boot from SATA hard drives at all (I've tested this with multiple SATA drives so it's definitely not a problem related to faulty drives). As soon as OpenBSD is installed on a SATA hard drive, the ASUS boot screen completely freezes such that it doesn't even reach the OpenBSD boot loader (diagnostic HDD LED shows a problem). In particular, I did the following tests: 1) blank hard drive - mainboard boots another disk/system without problems 2) SATA hard drive after fdisk -iy sd0 - mainboard boots another disk/system without problems 3) SATA hard drive after creating partitions via disklabel (no installboot(8)) -- ASUS boot screen freezes 4) SATA hard drive with freshly installed OpenBSD current system (via CDROM) -- ASUS boot screen freezes I suppose this is a (software) problem with the mainboard (BIOS/EFI/wtf...) and not with OpenBSD. So take this as a warning in case you're playing with the thought of buying this particular mainboard model for OpenBSD at this time. In case ASUS fixes this problem, I'll inform the list. I haven't tried booting OpenBSD via grub yet - maybe this will work around the problem. Did anyone experience similar problems in the past? Does anybody know a mainboard for Haswell E3-Xeons which works well with OpenBSD? Best Regards Andreas dmesg after booting OpenBSD via USB stick: OpenBSD 5.4-current (GENERIC.MP) #0: Sat Aug 24 11:04:26 CEST 2013 root@test:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8508362752 (8114MB) avail mem = 8273772544 (7890MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeba50 (87 entries) bios0: vendor ASUSTeK COMPUTER INC. (Licensed from AMI) version 1205 date 07/30/2013 bios0: ASUS All Series acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT SSDT SSDT MCFG HPET SSDT SSDT DMAR BGRT acpi0: wakeup devices UAR1(S4) PS2K(S4) PS2M(S4) PXSX(S4) RP01(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(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) Xeon(R) CPU E3-1230 v3 @ 3.30GHz, 3292.82 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz, 3292.38 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM 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) Xeon(R) CPU E3-1230 v3 @ 3.30GHz, 3292.38 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM 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) Xeon(R) CPU E3-1230 v3 @ 3.30GHz, 3292.38 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM 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) Xeon(R) CPU E3-1230 v3 @ 3.30GHz, 3292.38 MHz 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu4: 256KB 64b/line 8-way L2 cache
Re: softdep issue in 5.3-current ?
The reported problems are gone in CURRENT: # dmesg|head -n2 OpenBSD 5.4 (GENERIC.MP) #0: Sat Jul 20 17:56:10 CEST 2013 root@test:/usr/src/sys/arch/amd64/compile/GENERIC.MP time buildsrc.sh takes 31 minutes. measured directly after building src (which was slow before): # time tar -xzpf /usr/releasedir/comp54.tgz 0m5.67s real 0m2.07s user 0m0.89s system # time tar -xzpf /usr/releasedir/man54.tgz 0m1.26s real 0m0.45s user 0m0.30s system Best Regards Andreas
Re: softdep issue in 5.3-current ?
On 07/03/13 05:45, Andreas Bartelt wrote: I made a new build of current and the problem with tar performance seems to be resolved now. before: # time tar -xzpf /usr/releasedir/comp53.tgz 3m17.81s real 0m2.14s user 0m2.22s system # time tar -xzpf /usr/releasedir/base53.tgz 3m39.33s real 0m2.23s user 0m2.23s system after: # dmesg|head -n2 OpenBSD 5.3-current (GENERIC.MP) #0: Tue Jul 2 22:44:07 CEST 2013 root@test:/usr/src/sys/arch/amd64/compile/GENERIC.MP # time tar -xzpf /usr/releasedir/comp53.tgz 0m8.92s real 0m1.80s user 0m1.07s system # time tar -xzpf /usr/releasedir/base53.tgz 0m11.29s real 0m2.21s user 0m1.17s system I was wrong -- the problem persists! Directly after booting into a system built with the current source, tar extraction performance is OK (like in my second example from above), but after 'make build make release' of current source on the same system, tar extraction performance is horrible (like in the first example from above). So tar extraction performance seems to get much worse after the system was under heavy I/O for a while (i.e., after make build make release). Can anyone reproduce this? Best Regards Andreas
Re: softdep issue in 5.3-current ?
I made a new build of current and the problem with tar performance seems to be resolved now. before: # time tar -xzpf /usr/releasedir/comp53.tgz 3m17.81s real 0m2.14s user 0m2.22s system # time tar -xzpf /usr/releasedir/base53.tgz 3m39.33s real 0m2.23s user 0m2.23s system after: # dmesg|head -n2 OpenBSD 5.3-current (GENERIC.MP) #0: Tue Jul 2 22:44:07 CEST 2013 root@test:/usr/src/sys/arch/amd64/compile/GENERIC.MP # time tar -xzpf /usr/releasedir/comp53.tgz 0m8.92s real 0m1.80s user 0m1.07s system # time tar -xzpf /usr/releasedir/base53.tgz 0m11.29s real 0m2.21s user 0m1.17s system Best Regards Andreas
Re: softdep issue in 5.3-current ?
On 06/29/13 08:15, Philip Guenther wrote: On Fri, Jun 28, 2013 at 10:25 PM, Andreas Bartelt o...@bartula.de wrote: I also noticed that tar performance got much worse on current, and time for building release doubled somewhere around the first half of June. Hmm, please excuse my frustration, but I'm going to have to rant a moment. Gah! Build performance *was cut in half* and you didn't say anything until *at least two weeks later*!?!? No last known good date given for when things were fast. No date given for when you first noticed that it had slowed down. No definitive time measurements. No dmesg or information about the system involved (softdeps? NFS? hell, *architecture*?!?!) additional text deleted Folks, if you're following -current and see a support or performance regression, SAY SOMETHING. We test as much as we believe necessary and reasonable, which means that sometimes we miss cases that are actually show-stoppers and other times we're simply wrong. Delays in reporting just make it harder. sorry, I'm quite busy atm. My last known good /bsd.mp kernel is from June 7: OpenBSD 5.3-current (GENERIC.MP) #0: Fri Jun 7 07:15:17 CEST 2013 I first noticed this problem a couple of days later. I usually build release via the following script (12 cores, hyperthreading deactivated): # cat buildsrc.sh #!/bin/sh cd /usr/src \ make obj \ cd etc \ env DESTDIR=/ make distrib-dirs \ cd /usr/src \ make -j12 build \ export DESTDIR=/usr/destdir; export RELEASEDIR=/usr/releasedir \ cd /usr/src/etc \ make -j12 release \ cd /usr/src/distrib/sets \ sh checkflist \ unset RELEASEDIR DESTDIR time ./buildsrc.sh took about 41 minutes at 5.3 release, then went down to 32 minutes at some point afterwards. At some point after June 7th, build time doubled to 64 minutes. As I already mentioned, tar got very slow. softdep is enabled on this box, kern.bufcachepercent=40, system is on a raid0 drive which spans over 2 ciss(4) HW raid1 drives. ciss(4) performance generally isn't optimal but I suppose this isn't directly related to the problem described above. # mount /dev/sd2a on / type ffs (local, noatime, softdep) /dev/sd2e on /usr type ffs (local, noatime, nodev, softdep) /dev/sd2d on /var type ffs (local, noatime, nodev, nosuid, softdep) # bioctl sd2 Volume Status Size Device softraid0 0 Online 599704600576 sd2 RAID0 0 Online 299852318720 0:0.0 noencl sd0d 1 Online 299852318720 0:1.0 noencl sd1d Best Regards Andreas OpenBSD 5.3-current (GENERIC.MP) #0: Thu Jun 27 22:50:00 CEST 2013 root@test:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17152794624 (16358MB) avail mem = 16688459776 (15915MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf7fe000 (127 entries) bios0: vendor HP version P68 date 01/28/2011 bios0: HP ProLiant DL360 G7 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP SPCR MCFG HPET SPMI ERST APIC SRAT BERT HEST DMAR SSDT SSDT SSDT SSDT SSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU X5650 @ 2.67GHz, 2667.16 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 133MHz cpu1 at mainbus0: apid 32 (application processor) cpu1: Intel(R) Xeon(R) CPU X5650 @ 2.67GHz, 2666.77 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 0, package 1 cpu2 at mainbus0: apid 16 (application processor) cpu2: Intel(R) Xeon(R) CPU X5650 @ 2.67GHz, 2666.77 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 8, package 0 cpu3 at mainbus0: apid 48 (application processor) cpu3: Intel(R) Xeon(R) CPU X5650 @ 2.67GHz, 2666.76 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 8, package 1 cpu4 at mainbus0: apid
Re: softdep issue in 5.3-current ?
On 06/29/13 11:18, Ville Valkonen wrote: On 29 June 2013 09:51, Andreas Bartelt o...@bartula.de wrote: snip time ./buildsrc.sh took about 41 minutes at 5.3 release, then went down to 32 minutes at some point afterwards. At some point after June 7th, build time doubled to 64 minutes. /snip Hi Andreas, story doesn't tell whether you have sysctl kern.pool_debug set to 0. Is it? In release it is, in current it is not. yep, forgot to mention this... kern.pool_debug was set to 0 during all these measurements. All measurements were done on current -- with 41 minutes at 5.3 release I actually meant the approximate time when 5.3 was released. The build time improvement to 32 minutes happened about mid-May, if I remember correctly. # cat /etc/sysctl.conf |grep -v ^# kern.pool_debug=0 kern.bufcachepercent=40 Best Regards Andreas
Re: softdep issue in 5.3-current ?
On 06/26/13 12:35, Tori Mus wrote: Hi, I'm running current snapshot of OpenBSD on amd64 architecture, MP kernel (Lenovo Thinkpad to be concrete). Based on the official docs tried to tune disk performance by adding `softdep' mounting option for ffs slices. After updating of /etc/fstab and clean reboot, checked all particular slices like /home, /usr etc. are really mounted with softdep. The issue is about much worse performance then with the default nosoftdep. Now, for example, when extracting ports.tar.gz snapshot in /usr, other process cann't open even small files without very long delays like vi $HOME/.profile takes about 2 minutes whereas cpu usage shown with top is about 5% only ! Turning off softdep redeems the access time of the previous example to about 4 seconds. I've searched mailing lists and read about softdep regression on OpenBSD 4.8 that was later fixed. Is this regression back. Does anybody else experiences similar behaviour ? I also noticed that tar performance got much worse on current, and time for building release doubled somewhere around the first half of June. Best Regards Andreas
Re: yubikey OTP, xlock(1) and /var/db/yubikey/`user`.ctr permissions
On 12/06/12 00:22, Alexander Hall wrote: On 12/02/12 14:31, Andreas Bartelt wrote: Hello, I've set up yubikey OTP authentication and also want to use it for xlock(1) authentication. /var/db/yubikey has permissions 770 for root:auth. In case no `user`.ctr file exists in /var/db/yubikey at first login via yubikey, it is created automatically with permissions 644. This fails in case of xlock(1) authentication via yubikey: [from /var/log/authlog] yubikey: user test: fopen: /var/db/yubikey/test.ctr: Permission denied Changing `user`.ctr permissions to 660 for root:auth makes it work. Should 660 be the default permissions for `user`.ctr? Yeah, that makes sense. I remember having issues with xlock myself but I didn't investigate it enough it seems. Does the diff below fix your issues? yes, permissions for `user`.crt are set correctly now. Thanks, Andreas
yubikey OTP, xlock(1) and /var/db/yubikey/`user`.ctr permissions
Hello, I've set up yubikey OTP authentication and also want to use it for xlock(1) authentication. /var/db/yubikey has permissions 770 for root:auth. In case no `user`.ctr file exists in /var/db/yubikey at first login via yubikey, it is created automatically with permissions 644. This fails in case of xlock(1) authentication via yubikey: [from /var/log/authlog] yubikey: user test: fopen: /var/db/yubikey/test.ctr: Permission denied Changing `user`.ctr permissions to 660 for root:auth makes it work. Should 660 be the default permissions for `user`.ctr? Best Regards Andreas
Re: ciss(4) write very slow w/o bbwc
Hello, On 05/29/12 17:28, Kenneth R Westerback wrote: On Tue, May 29, 2012 at 03:48:02PM +0200, csszep wrote: Hi! So i tested the ciss performance with Openbsd 5.1 and Netbsd 5.1.2 and the numbers are the same. :( approx 13Mbyte/s write with dd if=/dev/zero of=/dev/rsd1c bs=1m count=500 But why Linux is four times faster (approx 40Mbyte/s)? Dunno. But the diff below should apply the NetBSD 'fix' for the INQUIRY command. Ken Dunno. But the diff below should apply the NetBSD 'fix' for the INQUIRY command. I also can confirm relatively slow ciss(4) performance on OpenBSD. Enabling the (not battery backed) cache via BIOS doesn't help significantly. I just did some tests on a HP Proliant DL360G7 with RAID1 via ciss(4) with 2x300GB 6G SAS 1 rpm HDDs (cache disabled on this box): # disklabel sd0 # /dev/rsd0c: type: SCSI disk: SCSI disk label: LOGICAL VOLUME duid: 410f0efc5a9d86dd flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 36468 total sectors: 585871964 boundstart: 64 boundend: 585858420 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 1028096 64 4.2BSD 2048 163841 # / c:5858719640 unused d: 1028160 1028160 4.2BSD 2048 163841 # /var e:146801952 2056320 4.2BSD 2048 163841 # /usr f: 20964832148858272 4.2BSD 2048 163841 # /home g:416035264169823104 4.2BSD 4096 327681 # /log # mount /dev/sd0a on / type ffs (local, noatime, softdep) /dev/sd0f on /home type ffs (local, noatime, nodev, nosuid, softdep) /dev/sd0g on /log type ffs (local, noatime, nodev, nosuid, softdep) /dev/sd0e on /usr type ffs (local, noatime, nodev, softdep) /dev/sd0d on /var type ffs (local, noatime, nodev, nosuid, softdep) # dmesg|grep ciss ciss0 at pci1 dev 0 function 0 Hewlett-Packard Smart Array rev 0x01: apic 0 int 4 ciss0: 2 LDs, HW rev 2, FW 3.66/3.66, 64bit fifo rro scsibus0 at ciss0: 2 targets before applying your patch: [/usr] # dd if=/dev/zero of=testfile bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 16.428 secs (63825353 bytes/sec) [/usr] # dd if=/dev/zero of=testfile bs=1m count=1 1+0 records in 1+0 records out 1048576 bytes transferred in 153.910 secs (68128911 bytes/sec) [/log] # dd if=/dev/zero of=testfile bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 8.122 secs (129087680 bytes/sec) [/log] # dd if=/dev/zero of=testfile bs=1m count=1 1+0 records in 1+0 records out 1048576 bytes transferred in 87.701 secs (119561580 bytes/sec) after applying your patch: [/usr] # dd if=/dev/zero of=testfile bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 14.113 secs (74296489 bytes/sec) [/usr] # dd if=/dev/zero of=testfile bs=1m count=1 1+0 records in 1+0 records out 1048576 bytes transferred in 154.600 secs (67824996 bytes/sec) [/log] # dd if=/dev/zero of=testfile bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 6.836 secs (153379539 bytes/sec) [/log] # dd if=/dev/zero of=testfile bs=1m count=1 1+0 records in 1+0 records out 1048576 bytes transferred in 82.955 secs (126402027 bytes/sec) The larger fsize/bsize of partition sd0g almost seems to double the writing throughput in comparison to partition sd0e. I didn't expect this much of a difference. Regarding performance, copying many small files (~190 MB) is much worse (time is identical before and after the patch): [/log/test] # date ; cp -Rp /usr/src/sys . ; date Tue May 29 20:42:32 CEST 2012 Tue May 29 20:43:15 CEST 2012 Best Regards Andreas
Re: The keyboard doesn't work in X after the most recent update
Hello Norman, On 11/05/11 20:13, Norman Golisz wrote: ... since 5.0, xenocara uses xkeyboard-config instead of the old /etc/X11/xkb. In the last couple of days, some code has been changed in xkeyboard-config, however, and made keyboards in X non-functional, when the /usr/X11R6/share/X11/xkb/symbols/srvr_ctrl directory was present. This directory was removed and replaced by a bare file [1]. So, chances are, older versions are not affected on your netbook. Thx -- I suppose I missed the part with the single file. The keyboard works now under Xorg on current. Best Regards Andreas
Re: The keyboard doesn't work in X after the most recent update
On 11/05/11 15:39, tkdchen wrote: Hi all, My keyboard does not work in fvwm, GNOME or KDE after the most recent update. No key response except the Fn+brightness-up and down. I run 5.0-current on Thinkpad x201i. Thanks a lot for your help. I've noticed that the keyboard of an Asus EEE 701 also doesn't work with Xorg on current (I followed the steps from current.html). However, I didn't test any older versions of OpenBSD on this netbook. Does anybody know if this a known or a new problem with this model? Best Regards Andreas
IPv6 source address vs. outgoing interface
Hello, one of my hosts has one wired and one wireless interface, and both interfaces have /64 IPv6 addresses in different subnets. I've noticed that this host doesn't use the IPv6 address of the outgoing interface (i.e., the wireless interface) as its source address, but, instead, the IPv6 address of the wired interface. I've seen this even when the wired interface is down. According to the routing table, I don't understand why the IPv6 address of the wired interface should be used in this case. I've already tried to increase the priority of the wireless interface (to priority 0), but this doesn't help. Example: wired interface: 2001:db8:10:10::2/64 wireless interface: 2001:db8:100:100::2/64 destination address: 2001:db8:10:20::1/64 The default route is set to the router address 2001:db8:100:100::1, so the wireless interface is the outgoing interface. The router with the address 2001:db8:100:100::1 can directly reach 2001:db8:10:20::1 by using its interface with address 2001:db8:10:20::2/64. What surprises me is that although the correct outgoing (wireless) interface is used, an IPv6 packet to 2001:db8:10:20::1 has the source address of the wired interface 2001:db8:10:10::2. Regards Andreas
Re: IPv6 source address vs. outgoing interface
On 06/19/11 12:09, Claudio Jeker wrote: On Sun, Jun 19, 2011 at 11:30:19AM +0200, Andreas Bartelt wrote: ... What surprises me is that although the correct outgoing (wireless) interface is used, an IPv6 packet to 2001:db8:10:20::1 has the source address of the wired interface 2001:db8:10:10::2. Welcome to IPv6 where source address selection is so complex that nobody understands it. In the end it often selects the address that is numerically closest to the destination. So yes, IPv6 tends to do stupid things and this is actually the way IETF wants it to be. Another reason why most of the network stack hackers think IPv6 is broken by design. so this means 'antispoof' and 'urpf-failed' rules in pf.conf(5) won't reliably work in the (IPv6) future? Could please someone invent a new Internet? Regards, Andreas
Re: tcpdump shows packets going from 0.0.0.0.0 0.0.0.0.0, what does this mean?
Hello Brett, On 05/22/11 09:02, Brett Mahar wrote: Hi misc, I have been playing around with pf lately, and have noticed a bunch of packets going from 0.0.0.0.0 to 0.0.0.0.0. I know 0.0.0.0 sometimes means the network address, but am not sure why these packets are getting through the firewall, or even if they are. Also, when tcpdump says (for example) rule 8 does that mean the 8th line in the output of pfctl -sr? I cannot find an explanation on website or man pages. I'm also seeing this for my pass in log (all to pflog0) ... rules. If you remove the all keyword, you'll see the the correct IP addresses at session initialization in the logs. Best regards Andreas
hostname.if(5)/ifconfig(8) configuration for gif(4)
Hello, I'm able to use the following configuration for gif0 via ifconfig(8): # ifconfig gif0 inet6 tunnel 2002:db8::1 2002:db8::2 # ifconfig gif0 192.168.1.1 192.168.1.2 netmask 255.255.255.0 The following version of /etc/hostname.gif0 doesn't work: # cat /etc/hostname.gif0 inet6 tunnel 2002:db8::1 2002:db8::2 inet 192.168.1.1 255.255.255.0 dest 192.168.1.2 Is there a way to do this correctly via /etc/hostname.gif0 ? Best regards Andreas
Re: 4.0-stable panic with pppoe(4)
Tamas TEVESZ wrote: ok, so i'm not *entirely* sure it's with pppoe(4), but as far as i can put bits and pieces together, it's always happening after ifconfig pppoe0 down; ifconfig pppoe0 destroy and then either sh /etc/netstart pppoe0 or (the second case) starting ppp(8). ... it doesn't happen absolutely all the time, but it does happen quite regularly every other day or so. I can't help you but I can confirm that I had similar problems with CURRENT some time ago. I'm quite sure my problems were related to pppoe(4) since it never happened again after switching back to pppoe(8). My DSL provider disconnects my link every 24 hours -- the crashes didn't happen at every disconnect, but when the box crashed it was always at these times. I don't know if it helps, but after one of these crashes, I gathered the following output: ddb show panic lockmgr: process context required ddb ps PID PPID PGRPUID S FLAGS WAIT COMMAND 4737 19093 19093 67 3 0x184 netcon httpd 15818 19093 19093 67 3 0x184 netcon httpd 7615 1 7615 0 3 0x4086 ttyin getty 20778 1 20778 0 3 0x4086 ttyin getty 7938 1 7938 0 3 0x4086 ttyin getty 2538 1 2538 0 3 0x4086 ttyin getty 3443 1 3443 0 3 0x4086 ttyin getty 29660 1 29660 0 3 0x4086 ttyin getty 15563 1 15563 0 30x84 select cron 9403 1 9403528 3 0x184 poll stunnel 10302 31547 20993 0 30x84 netio tcpdump 21817 1 21817 0 30x84 poll popa3d 31547 20993 20993 76 3 0x4184 bpftcpdump 20993 1 20993 0 30x84 piperd spamlogd 20917 24424 24424 62 3 0x184 piperd spamd 8563 24424 24424 62 3 0x184 select spamd 24424 1 24424 62 3 0x184 nanosleep spamd 17158 1 17158 0 3 0x40184 select sendmail 28269 1 28269 0 30x84 select sshd 4876 19093 19093 67 3 0x184 netcon httpd 25319 19093 19093 67 3 0x184 netcon httpd 19008 19093 19093 67 3 0x184 netcon httpd 4428 19093 19093 67 3 0x184 netcon httpd 25455 19093 19093 67 3 0x184 netcon httpd 19093 1 19093 67 3 0x184 select httpd 16469 32727 32727 83 3 0x184 poll ntpd 32727 1 32727 0 30x84 poll ntpd 22531 10315 10315 70 3 0x184 select named 10315 1 10315 0 3 0x184 netio named 25289 3294 3294 74 3 0x184 bpfpflogd 3294 1 3294 0 30x84 netio pflogd 13918 19521 19521 73 2 0x184 syslogd 19521 1 19521 0 30x8c netio syslogd 16 0 0 0 30x100204 crypto_wa crypto 15 0 0 0 30x100204 aiodoned aiodoned 14 0 0 0 30x100204 syncer update 13 0 0 0 30x100204 cleanercleaner 12 0 0 0 30x100204 reaper reaper 11 0 0 0 30x100204 pgdaemon pagedaemon 10 0 0 0 30x100204 pftm pfpurge 9 0 0 0 30x100204 wait wskbd_hotkey 8 0 0 0 30x100204 usbevt usb3 7 0 0 0 30x100204 usbevt usb2 6 0 0 0 30x100204 usbevt usb1 5 0 0 0 30x100204 usbtsk usbtask 4 0 0 0 30x100204 usbevt usb0 3 0 0 0 30x100204 apmev apm0 2 0 0 0 30x100204 kmallockmthread 1 0 1 0 3 0x4084 wait init 0 -1 0 0 3 0x80204 scheduler swapper ddb trace Debugger(d077c5e0,d5dfda24,d0895a6c,10012,d073e5c4) at Debugger+0x4 panic(d0666aa0,d0895adc,d0895a44,d02d07ce,0) at panic+0x63 lockmgr(d073e5c4,10012,d073e664,0) at lockmgr+0xbb uvm_map_p(d073e5c0,d0895ae4,1000,d073e560,,,0,1323,0,6,d0895b04 ,d0e2e980) at uvm_map_p+0x4c6 uvm_km_kmemalloc(d073e5c0,d073e560,1000,1,80) at uvm_km_kmemalloc+0x57 uvm_km_alloc_poolpage1(d073e5c0,d073e560,0,0,d0756d80) at uvm_km_alloc_poolpage 1+0x2e pool_page_alloc_oldnointr(d0756d80,0,d0895b84,d038d13c,e277f270) at pool_page_a lloc_oldnointr+0x29
Exploit mitigation techniques and kernel code
Hi all, after reading the recent CORE advisory about the mbuf handling bug, I was wondering if some of OpenBSD's exploit mitigation strategies could also be applied to the kernel in order to prevent exploitation of kernel bugs. Theo's presentation about exploit mitigation ( http://openbsd.org/papers/ven05-deraadt/index.html ) mentions Stackgap, ProPolice/SSP, W^X/NX bit, ld.so randomization, randomized malloc, .rodata segment, StackGhost (on Sparc/Sparc64), privilege revocation/separation, which all seem to have been introduced in order to protect buggy userland code from being exploited (please correct me if I'm wrong). Are there any known techniques for also protecting kernel code, which could be implemented in OpenBSD, i.e., would it be technically feasible (or would it make any sense) to implement some address randomization to a kernel image after it has been initially loaded into memory? Does W^X also apply to kernel code, i.e., could it be applied in order to prevent maliciously introduced code from execution inside the kernel? In other words: is a bug-free kernel the only way to eventually render a system secure against such attacks? And if this is so, does this mean that microkernel designs are in fact inherently more secure than monolithic kernels, because they allow for a better reduction of the attack surface which can't be achieved with alternative strategies? In other words: regarding security, is Prof. Tanenbaum actually right with his preference for microkernels in his books about operating systems? I'm aware that my questions must look quite silly to you kernel developers, but I am wondering about these things for quite some time now -- it would be great if someone could shed some light on this, or just point me to some relevant literature. regards, Andreas
pkg_add(1) over ssh(1)?
Hi, is there any documentation about using pkg_add over ssh available yet? Can this feature be used with some of the official mirrors? regards, Andreas
Re: pkg_add(1) over ssh(1)?
Will Maier wrote: On Wed, Nov 01, 2006 at 07:45:16PM +0100, Andreas Bartelt wrote: is there any documentation about using pkg_add over ssh available yet? pkg_add(1); look for 'scp://'... thanks, I didn't see it. Can this feature be used with some of the official mirrors? If you have ssh access on them, sure. you mean a regular user account or can it be done with a passwordless account (similar to anoncvs)?
Re: pkg_add(1) over ssh(1)?
John Fiore wrote: is there any documentation about using pkg_add over ssh available yet? Can this feature be used with some of the official mirrors? Just out of curiosity, why would you want to do this? pkg_add verifies the packages after downloading them. Is this some kind of firewalling issue? AFAIK, in contrast to building packages from source, pkg_add(1) doesn't do any checks for integrity/authenticity (this would require procedures for signing packets and a corresponding PKI). By relying on the ssh host keys from the official OpenBSD mirror website, the use of pkg_add over ssh would make sure that packages can't be modified on the way from the mirror to the upgrading machine. This isn't perfect, but it would certainly be an improvement (similar to anoncvs via ssh). Moreover, the short description of this feature in the 4.0 release notes suggests that upgrades via ssh will be tunneled through a single connection, which would be more efficient than the current ftp variant.
Re: console screensafer
Andreas Bartelt wrote: ... thanks, you made me look at my BIOS and (at least I think) I found the cause. There's an option called Video Off method, which was set to DPMS support. I just switched it to blank screen and didn't experience the usual problems after rebooting. I think (hope ;) ) this solved the problem. I'm replying to myself here. I wrote this on August, 5th, and I thought the problem was gone. I was wrong! The problem was not gone and changing the video off method configuration in the BIOS didn't help at all (I've tried all settings related to this...). Now, I can provide some more weird facts about this problem: - I can successfully work around this problem by turning my PC on _without_ turning on my monitor. Then, I login blindly and start Xorg (XFCE4). If I turn on my monitor _after_ this procedure, I have no switching off problems with my monitor. Curiously, this procedure always works. - If I turn on the monitor at some point _before_ starting Xorg, I _always_ have this switching on/off problem with my monitor, until I turn the monitor off (and wait a few seconds) and, then, turn it on again. After this procedure, the problem is also gone. Furthermore, this problem does only occur after turning my PC on for the first time (most of the time, it works after rebooting if I don't wait too long before starting Xorg...). - the graphics card doesn't seem to be the cause (I've tried a Radeon 9600 and a Geforce 2). - I don't have similar problems when I boot Windows XP, so I don't think it's my hardware. Now, this alone looks like a real problem, but there's more... After upgrading CURRENT on August, 26th (I didn't upgrade since August, 5th), I have even more problems related to the console. After exiting Xorg (I use XFCE4 as desktop environment), the console behaves totally weird. Most of the time, I just see a black screen and no more console output. Sometimes, there are just fields of black and grey (and blue shades for kernel messages ;) ) on the monitor. Entering commands with the keyboard still works, but there's no readable feedback on the screen at all. I've also tested this with the Radeon 9600 and the Geforce 2 card. regards, Andreas
Re: console screensafer
Andreas Bartelt wrote: ... sorry, I forgot a add dmesg output... OpenBSD 4.0-beta (GENERIC) #0: Sat Aug 26 05:17:41 CEST 2006 [EMAIL PROTECTED]:/home/a/src/sys/arch/i386/compile/GENERIC cpu0: AMD Athlon(tm) XP 2600+ (AuthenticAMD 686-class, 512KB L2 cache) 1.93 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real mem = 536375296 (523804K) avail mem = 481320960 (470040K) using 4256 buffers containing 26923008 bytes (26292K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(6e) BIOS, date 07/17/03, BIOS32 rev. 0 @ 0xfb990, SMBIOS rev. 2.3 @ 0xf (37 entries) bios0: MICRO-STAR INTERNATIONAL CO., LTD MS-6570 apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 70102 dobusy 1 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xf/0xd8e4 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfd820/192 (10 entries) pcibios0: PCI Exclusive IRQs: 3 5 10 11 pcibios0: no compatible PCI ICU found pcibios0: Warning, unable to fix up PCI interrupt routing pcibios0: PCI bus #3 is the last bus bios0: ROM list: 0xc/0xd000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 NVIDIA nForce2 PCI rev 0xc1 NVIDIA nForce2 rev 0xc1 at pci0 dev 0 function 1 not configured NVIDIA nForce2 rev 0xc1 at pci0 dev 0 function 2 not configured NVIDIA nForce2 rev 0xc1 at pci0 dev 0 function 3 not configured NVIDIA nForce2 rev 0xc1 at pci0 dev 0 function 4 not configured NVIDIA nForce2 rev 0xc1 at pci0 dev 0 function 5 not configured pcib0 at pci0 dev 1 function 0 NVIDIA nForce2 ISA rev 0xa3 nviic0 at pci0 dev 1 function 1 NVIDIA nForce2 SMBus rev 0xa2 iic0 at nviic0 iic0: addr 0x2f 04=00 06=02 07=00 0c=00 0d=07 0e=84 0f=00 10=ca 11=10 12=00 13=60 14=14 15=62 16=01 17=06 iic1 at nviic0 ohci0 at pci0 dev 2 function 0 NVIDIA nForce2 USB rev 0xa3: irq 5, version 1.0, legacy support usb0 at ohci0: USB revision 1.0 uhub0 at usb0 uhub0: NVIDIA OHCI root hub, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1 at pci0 dev 2 function 1 NVIDIA nForce2 USB rev 0xa3: irq 10, version 1.0, legacy support usb1 at ohci1: USB revision 1.0 uhub1 at usb1 uhub1: NVIDIA OHCI root hub, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ehci0 at pci0 dev 2 function 2 NVIDIA nForce2 USB rev 0xa3: irq 11 usb2 at ehci0: USB revision 2.0 uhub2 at usb2 uhub2: NVIDIA EHCI root hub, rev 2.00/1.00, addr 1 uhub2: 6 ports with 6 removable, self powered NVIDIA nForce2 Audio rev 0xa2 at pci0 dev 5 function 0 not configured auich0 at pci0 dev 6 function 0 NVIDIA nForce2 AC97 rev 0xa1: irq 5, nForce2 AC97 ac97: codec id 0x414c4720 (Avance Logic ALC650) ac97: codec features 20 bit DAC, 18 bit ADC, Realtek 3D audio0 at auich0 ppb0 at pci0 dev 8 function 0 NVIDIA nForce2 PCI-PCI rev 0xa3 pci1 at ppb0 bus 1 xl0 at pci1 dev 7 function 0 3Com 3c905 100Base-TX rev 0x00: irq 11, address 00:60:08:69:8b:5d nsphy0 at xl0 phy 24: DP83840 10/100 PHY, rev. 1 pciide0 at pci0 dev 9 function 0 NVIDIA nForce2 IDE rev 0xa2: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: SAMSUNG SV1203N wd0: 16-sector PIO, LBA48, 114498MB, 234493056 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 wd1 at pciide0 channel 1 drive 0: SAMSUNG SV1604N wd1: 16-sector PIO, LBA48, 152627MB, 312581808 sectors wd1(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 5 ppb1 at pci0 dev 30 function 0 NVIDIA nForce2 AGP rev 0xc1 pci2 at ppb1 bus 3 vga1 at pci2 dev 0 function 0 ATI Radeon 9600 Pro rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ATI Radeon 9600 Pro Sec rev 0x00 at pci2 dev 0 function 1 not configured isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pmsi0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pmsi0 mux 0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 lm0 at isa0 port 0x290/8: W83627HF npx0 at isa0 port 0xf0/16: using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec biomask ef6d netmask ef6d ttymask ffef pctr: user-level cycle counter enabled mtrr: Pentium Pro MTRR support dkcsum: wd0 matches BIOS drive 0x80 dkcsum: wd1 matches BIOS drive 0x81 root on wd0a rootdev=0x0 rrootdev=0x300 rawdev=0x302 auich0: measured ac97 link rate at 48008 Hz, will use 48000 Hz
mirroring packages without much bandwidth overhead
Hi, is there a simple way to efficiently mirror packages solely based on package filenames in order to reduce bandwidth overhead? I've tried to do this with rsync but as packages are constantly rebuilt, file size of packages changes regularly, and, therefore, the rsync option '--size-only' (which ignores timestamps) is insufficient for my purposes. I'd like to sync packages solely based on their file name. Is there a way to do this with rsync or with another tool? regards, Andreas
console screensafer
Hi, is there a way to disable to console screensafer in OpenBSD? Problem description: after about 60 seconds after booting, the console screen blanks and my monitor turns off (disabling power management on my monitor doesn't help). Sometimes, shortly after starting Xorg, my monitor also turns off. During a fresh installation of CURRENT from a default floppy, my monitor also turns off. I tried the following values in /etc/wsconsctl.conf, but they didn't have any obvious effect: display.vblank=off display.screen_off=600 regards, Andreas
Re: console screensafer
Hi, Bachman Kharazmi wrote: xorg.conf has a DPMS option which turns the monitor in powersave after a while. Check if that option appear in your xorg.conf. xset q also know if it's enabled or not. thanks for the hint. I suppose, I didn't describe the problem clearly. My Xorg screensafer works without problems: it blanks the screen after a while, and later, the monitor goes to standby mode. The monitor can be waked up again by moving the mouse or pressing a key on the keyboard -- no problems here. The problem is with the console (it begins without ever starting Xorg, i.e., during an installation of OpenBSD with a standard floppy -- so it's no configuration problem on my side). After about 60 seconds, the screen blanks and the monitor begins to turn on and off repeatedly (depending on the power management setup of my monitor, it sometimes also turns off straight). Its totally unusable then and it _can't_ be waked up again by pressing a key on the keyboard. The only workaround is to turn the monitor completely off and then on again, but it will resume this crazy behaviour again after a short period, if I don't start Xorg... I've noticed that sometimes the screen turns on and off the same way _immediately_ after starting Xorg, but I think this is directly related to the console problem, because after manually turning the monitor off and on again, the problem is resolved then and, as I said, the Xorg screensafer itself works without problems. I didn't experience this problem with the same hardware from the beginning (around OpenBSD 3.4), but I don't remember the exact point when I experienced this problem for the first time (I suppose it was around OpenBSD 3.8/3.9, but I'm not sure...). btw, I'm using a LaCie electron blue CRT monitor. regards, Andreas
Re: console screensafer
Hi, Nick Holland wrote: ... OpenBSD does not blank the console screen after booting without you deliberately setting things to do so. This is clearly not OpenBSD at work. Don't try to fix broken hardware configuration through OpenBSD, fix the hardware. You apparently have some strange feature in the BIOS of your hardware. Turn it off. I've seen these features on at least Compaqs and Dells, and heard of it on many others. thanks, you made me look at my BIOS and (at least I think) I found the cause. There's an option called Video Off method, which was set to DPMS support. I just switched it to blank screen and didn't experience the usual problems after rebooting. I think (hope ;) ) this solved the problem. regards, Andreas
Re: ftp: -: short write on current when using pkg_add on ftp mirrors
Hi, I'm still using the binary snapshot from July, 25th. maybe this strange problem is related to the other problem: tar -czvpf folder.tar.gz folder/ tar: Failed write to archive volume: 1: Broken pipe 'tar -cvpf ...' (without compression) works without problems. Could this problem be related to the short write problem during pkg_add? How can I fix it? regards, Andreas
Re: ftp: -: short write on current when using pkg_add on ftp mirrors
Hi, as nobody seems to be interested in this problem, this will be my last post and then I'll stop digging. I've tried a _binary_ snapshot from ftp.openbsd.org (from July, 25th) and it also gives me this short write error while using pkg_add per ftp. dmesg is attached to this mail (I don't know if the problems with nfe(4) are related to this problem). The following workaround solved the problem for me, so I'm happy now: - mirror all packages of an ftp mirror on my local filesystem and use pkg_add -ui -F update -F updatedepends directly on this path what still doesn't work: - using this local mirror-directory per ftp. I also get short write on my local network (PF is disabled, so this can't be the cause). regards, Andreas OpenBSD 3.9-current (GENERIC) #1019: Tue Jul 25 16:46:08 MDT 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: AMD Athlon(tm) XP 2600+ (AuthenticAMD 686-class, 512KB L2 cache) 1.93 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real mem = 536375296 (523804K) avail mem = 481550336 (470264K) using 4256 buffers containing 26923008 bytes (26292K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(6e) BIOS, date 07/17/03, BIOS32 rev. 0 @ 0xfb990, SMBIOS rev. 2.3 @ 0xf (37 entries) bios0: MICRO-STAR INTERNATIONAL CO., LTD MS-6570 apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 70102 dobusy 1 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xf/0xd8e4 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfd820/192 (10 entries) pcibios0: PCI Exclusive IRQs: 3 5 10 11 pcibios0: no compatible PCI ICU found pcibios0: Warning, unable to fix up PCI interrupt routing pcibios0: PCI bus #2 is the last bus bios0: ROM list: 0xc/0xd000 0xd/0x1800 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 NVIDIA nForce2 PCI rev 0xc1 NVIDIA nForce2 rev 0xc1 at pci0 dev 0 function 1 not configured NVIDIA nForce2 rev 0xc1 at pci0 dev 0 function 2 not configured NVIDIA nForce2 rev 0xc1 at pci0 dev 0 function 3 not configured NVIDIA nForce2 rev 0xc1 at pci0 dev 0 function 4 not configured NVIDIA nForce2 rev 0xc1 at pci0 dev 0 function 5 not configured pcib0 at pci0 dev 1 function 0 NVIDIA nForce2 ISA rev 0xa3 nviic0 at pci0 dev 1 function 1 NVIDIA nForce2 SMBus rev 0xa2 iic0 at nviic0 iic0: addr 0x2f 04=00 06=02 07=00 0c=00 0d=07 0e=84 0f=00 10=ca 11=10 12=00 13=60 14=14 15=62 16=01 17=06 iic1 at nviic0 ohci0 at pci0 dev 2 function 0 NVIDIA nForce2 USB rev 0xa3: irq 5, version 1.0, legacy support usb0 at ohci0: USB revision 1.0 uhub0 at usb0 uhub0: NVIDIA OHCI root hub, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1 at pci0 dev 2 function 1 NVIDIA nForce2 USB rev 0xa3: irq 10, version 1.0, legacy support usb1 at ohci1: USB revision 1.0 uhub1 at usb1 uhub1: NVIDIA OHCI root hub, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ehci0 at pci0 dev 2 function 2 NVIDIA nForce2 USB rev 0xa3: irq 11 usb2 at ehci0: USB revision 2.0 uhub2 at usb2 uhub2: NVIDIA EHCI root hub, rev 2.00/1.00, addr 1 uhub2: 6 ports with 6 removable, self powered nfe0 at pci0 dev 4 function 0 NVIDIA nForce2 LAN rev 0xa1: irq 11, address 00:0c:76:ff:b6:f0 icsphy0 at nfe0 phy 1: ICS1893 10/100 PHY, rev. 1 NVIDIA nForce2 Audio rev 0xa2 at pci0 dev 5 function 0 not configured auich0 at pci0 dev 6 function 0 NVIDIA nForce2 AC97 rev 0xa1: irq 5, nForce2 AC97 ac97: codec id 0x414c4720 (Avance Logic ALC650) ac97: codec features 20 bit DAC, 18 bit ADC, Realtek 3D audio0 at auich0 ppb0 at pci0 dev 8 function 0 NVIDIA nForce2 PCI-PCI rev 0xa3 pci1 at ppb0 bus 1 pciide0 at pci0 dev 9 function 0 NVIDIA nForce2 IDE rev 0xa2: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: SAMSUNG SV1203N wd0: 16-sector PIO, LBA48, 114498MB, 234493056 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 pciide0: channel 1 disabled (no drives) ppb1 at pci0 dev 30 function 0 NVIDIA nForce2 AGP rev 0xc1 pci2 at ppb1 bus 2 vga1 at pci2 dev 0 function 0 ATI Radeon 9600 Pro rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ATI Radeon 9600 Pro Sec rev 0x00 at pci2 dev 0 function 1 not configured isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pmsi0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pmsi0 mux 0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 lm0 at isa0 port 0x290/8: W83627HF npx0 at isa0 port 0xf0/16: using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec biomask ef6d netmask ef6d ttymask ffef pctr:
Re: ftp: -: short write on current when using pkg_add on ftp mirrors
Hi, I've compiled some older snapshots of CURRENT and the last time it worked for me was July, 12th 00:00 (the build failed at texinfo, but pkg_add -ui -F update -F updatedepends worked afterwards). A build from July, 14th 00:00 didn't work anymore, so I suppose the breakage was introduced on July 12th or 13th. There were no pkg_add or ftp related commits in this timeframe. What else could be the cause? regards, Andreas
Re: ftp: -: short write on current when using pkg_add on ftp mirrors
Hi, as nobody answers, I conclude I'm the only one experiencing this problem on CURRENT. I've rebuilt CURRENT today and the problem persists. I don't experience this problem on my OPENBSD_3_9 boxes (kernel from June, 17th). What exactly does this short write error message mean and what could be the cause of this problem? regards, Andreas
ftp: -: short write on current when using pkg_add on ftp mirrors
Hi all, there was a similar thread on misc@ a few days ago. I'm using current and can't update packages anymore. #export PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/i386/ #pkg_add -ui -F update -F updatedepends Error from ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/i386/: Unknown command. Error from ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/i386/: ftp: -: short write 421 Service not available, remote server has closed connection. Temporary error, sleeping 5 seconds ... I've tried a couple of ftp mirrors and not a single one did work. This error persists since a couple of weeks. The big surprise is that it works without problems on 3.9 boxes. Is there a way to make it also work on current? regards, Andreas
bug in tcsh-6.14.00p0 ?
Hi all,
after upgrading one of my boxes to OpenBSD 3.9, I couldn't log in with
tcsh any more. It looks like malloc options 'AFGJP' trigger a core dump
with tcsh.
I recompiled tcsh with debug symbols and ran gdb, which gives me the
following output:
# gdb /usr/local/bin/tcsh tcsh.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 i386-unknown-openbsd3.9...
Core was generated by `tcsh'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libtermlib.so.10.0...done.
Loaded symbols for /usr/lib/libtermlib.so.10.0
Reading symbols from /usr/lib/libc.so.39.0...done.
Loaded symbols for /usr/lib/libc.so.39.0
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
#0 update_vars (vp=0x826f0c80) at sh.set.c:75
75 HISTSUB = *pn;
(gdb) bt full
#0 update_vars (vp=0x826f0c80) at sh.set.c:75
pn = (Char *) 0x82b6bffc
#1 0x1c01d7c0 in doset (v=0x893b534c, c=0x83303600) at sh.set.c:309
e = (Char **) 0x0
p = (Char *) 0x826f0ca8
vp = (Char *) 0x826f0c80
op = 0
vecp = (Char **) 0x82b6bffc
hadsub = 0
subscr = 1006668716
flags = 2
first_match = 0
last_match = 0
changed = -2106651480
#2 0x1c00e95d in func (t=0x83303600, bp=0x3c007850) at sh.func.c:152
i = 2
#3 0x1c01be9e in execute (t=0x83303600, wanttty=11236, pipein=0x0,
pipeout=0x0, do_glob=1) at sh.sem.c:650
forked = 0
bifunc = (struct biltins *) 0x3c007850
pid = 0
pv = {557, 557}
csigmask = 0
onosigchld = 0
nosigchld = 0
#4 0x1c01c7df in execute (t=0x83303b40, wanttty=11236, pipein=0x0,
pipeout=0x0, do_glob=1) at sh.sem.c:710
forked = 0
bifunc = (struct biltins *) 0x0
pid = 0
pv = {0, 0}
csigmask = 0
onosigchld = 0
nosigchld = 0
#5 0x1c004ea9 in process (catch=0) at sh.c:2180
osetexit = {j = {469833313, 1, -809792948, -809792808,
1007006568, -809792840, 2, 0, 0, 0}}
t = (struct command *) 0x83303760
#6 0x1c0117fb in doeval (v=0x82b6bffc, c=0x83303f80) at sh.func.c:2372
oevalvec = (Char **) 0x0
oevalp = (Char *) 0x0
odidfds = 1
osetexit = {j = {469781503, 1, -809775860, -809775752, 1, 0, 2,
0, 0, 0}}
my_reenter = 0
savegv = (Char **) 0x0
saveIN = 6
saveOUT = 17
saveDIAG = 18
oSHIN = 6
oSHOUT = 17
oSHDIAG = 18
#7 0x1c00e95d in func (t=0x83303f80, bp=0x3c007680) at sh.func.c:152
i = 1
#8 0x1c01be9e in execute (t=0x83303f80, wanttty=11236, pipein=0x0,
pipeout=0x0, do_glob=1) at sh.sem.c:650
forked = 0
bifunc = (struct biltins *) 0x3c007680
pid = 0
---Type return to continue, or q return to quit---q
Is it a bug in tcsh or did I misconfigure malloc options? (sorry, I
don't have any experience in C debugging and actually don't know what
I'm doing...)
regards,
Andreas
Re: nfe0: tx v1 error 0x6001
Hi, Bob Bostwick (Lists) wrote: Anyone else get these errors with the nfe driver? Not really sure what to do to troubleshoot the problem. This seems to happen during heavy traffic times. nfe0: tx v1 error 0x6001 nfe0: watchdog timeout nfe0: tx v1 error 0x6001 nfe0: tx v1 error 0x6001 yes, I get similar messages with nfe(4). In my case it's a couple of times watchdog timeout followed by a single tx v1 error 0x6001 line. I get these messages always right after booting my machine. The nfe(4) interface begins working about 20 seconds after the initial login prompt appears (after or short before the tx v1 error 0x6001 line is shown), but after this deferred interface startup, all problems are gone. Just in case anybody wants to debug this issue, my dmesg is attached. regards, Andreas OpenBSD 3.9-current (GENERIC) #0: Mon Apr 24 18:35:45 CEST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: AMD Athlon(tm) XP 2600+ (AuthenticAMD 686-class, 512KB L2 cache) 1.93 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real mem = 536375296 (523804K) avail mem = 482365440 (471060K) using 4278 buffers containing 26923008 bytes (26292K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(6e) BIOS, date 07/17/03, BIOS32 rev. 0 @ 0xfb990 apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 70102 dobusy 1 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xf/0xd8e4 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfd820/192 (10 entries) pcibios0: PCI Exclusive IRQs: 3 5 10 11 pcibios0: no compatible PCI ICU found pcibios0: Warning, unable to fix up PCI interrupt routing pcibios0: PCI bus #2 is the last bus bios0: ROM list: 0xc/0xd000 0xd/0x1800 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 NVIDIA nForce2 PCI rev 0xc1 NVIDIA nForce2 rev 0xc1 at pci0 dev 0 function 1 not configured NVIDIA nForce2 rev 0xc1 at pci0 dev 0 function 2 not configured NVIDIA nForce2 rev 0xc1 at pci0 dev 0 function 3 not configured NVIDIA nForce2 rev 0xc1 at pci0 dev 0 function 4 not configured NVIDIA nForce2 rev 0xc1 at pci0 dev 0 function 5 not configured pcib0 at pci0 dev 1 function 0 NVIDIA nForce2 ISA rev 0xa3 nviic0 at pci0 dev 1 function 1 NVIDIA nForce2 SMBus rev 0xa2 iic0 at nviic0 iic0: addr 0x2f 04=00 06=02 07=00 0c=00 0d=07 0e=84 0f=00 10=ca 11=10 12=00 13=60 14=14 15=62 16=01 17=06 iic1 at nviic0 ohci0 at pci0 dev 2 function 0 NVIDIA nForce2 USB rev 0xa3: irq 11, version 1.0, legacy support usb0 at ohci0: USB revision 1.0 uhub0 at usb0 uhub0: NVIDIA OHCI root hub, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1 at pci0 dev 2 function 1 NVIDIA nForce2 USB rev 0xa3: irq 3, version 1.0, legacy support usb1 at ohci1: USB revision 1.0 uhub1 at usb1 uhub1: NVIDIA OHCI root hub, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ehci0 at pci0 dev 2 function 2 NVIDIA nForce2 USB rev 0xa3: irq 5 usb2 at ehci0: USB revision 2.0 uhub2 at usb2 uhub2: NVIDIA EHCI root hub, rev 2.00/1.00, addr 1 uhub2: 6 ports with 6 removable, self powered nfe0 at pci0 dev 4 function 0 NVIDIA nForce2 LAN rev 0xa1: irq 11, address 00:0c:76:ff:b6:f0 icsphy0 at nfe0 phy 1: ICS1893 10/100 PHY, rev. 1 ppb0 at pci0 dev 8 function 0 NVIDIA nForce2 PCI-PCI rev 0xa3 pci1 at ppb0 bus 1 emu0 at pci1 dev 9 function 0 Creative Labs SoundBlaster Live rev 0x05: irq 10 ac97: codec id 0x83847609 (SigmaTel STAC9721/23) ac97: codec features 18 bit DAC, 18 bit ADC, SigmaTel 3D audio0 at emu0 Creative Labs PCI Gameport Joystick rev 0x05 at pci1 dev 9 function 1 not configured pciide0 at pci0 dev 9 function 0 NVIDIA nForce2 IDE rev 0xa2: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: SAMSUNG SV1203N wd0: 16-sector PIO, LBA48, 114498MB, 234493056 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 pciide0: channel 1 disabled (no drives) ppb1 at pci0 dev 30 function 0 NVIDIA nForce2 AGP rev 0xc1 pci2 at ppb1 bus 2 vga1 at pci2 dev 0 function 0 ATI Radeon 9600 Pro rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ATI Radeon 9600 Pro Sec rev 0x00 at pci2 dev 0 function 1 not configured isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pmsi0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pmsi0 mux 0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 lm0 at isa0 port 0x290/8: W83627HF npx0 at isa0 port 0xf0/16: using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec biomask eb6d netmask eb6d ttymask fbef pctr: user-level cycle
Re: Blowfish still good enough?
Hi, knitti wrote: ... At least if there some quant. computers 128Bit will not save ya day anymore. quantum computers are the real big buzzword to scare people into irrational behaviour. nobody knows whether or when quantum computer will be able to brute force 128 bit keys. and whether twofish will save you. Bruce Schneier recommends using 256 bit keys in order to achieve 128 bit overall strength for a symmetric cipher. You can read it in 'applied cryptography'. The reason for this recommendation is related to collision attacks. In my personal opinion, I think, the weakest link is entering the password when opening a svnd device. Are there already solutions known which combine passwords (knowledge) with hardware devices (i.e. smartcards) or biometrics in order to access some secure storage? I don't own one, but don't at least a couple of newer IBM notebook models have a fingerprint reader and a TPM built in? Do you think a combination of these measures would improve overall security? regards, Andreas
Re: Blowfish still good enough?
Andreas Bartelt wrote: ... Bruce Schneier recommends using 256 bit keys in order to achieve 128 bit overall strength for a symmetric cipher. You can read it in 'applied cryptography'. The reason for this recommendation is related to collision attacks. oops, typo. It's in the newer book 'practical cryptography'. regards, Andreas
Re: browser security
Hi, James Strandboge wrote: On Thu, 2005-12-15 at 03:02 +0100, Andreas Bartelt wrote: ... Apache forks children with reduced priviledges (user www) while, at the same time, there's always an Apache process running as root. Therefore, a useful systrace policy for Apache probably won't be easy to write. No, apache is not running as root, parent or children: You're right. Sorry for spreading wrong information... regards, Andreas
Re: removing old files - /usr grows with each release
Hi, Matthias Kilian wrote: ... You could (ab)use the checkflist script in /usr/src/distrib sets, as mentioned in release(8): # cd /usr/src/distrib/sets # DESTDIR=/ sh checkflist foo Thanks for pointing me to release(8). In the end, I followed the steps described in release(8) and replaced the old /usr tree with the RELEASEDIR/usr tree. Afterwards, I reinstalled the previously installed ports. Besides the time required for a full 'make build', it was pretty easy and didn't require much user interaction. (disk usage after replacing /usr and reinstalling the same ports I was using before) df -h ... /dev/wd0e 359M277M 63.9M81%/usr Thanks a lot for all answers. regards, Andreas
removing old files - /usr grows with each release
Hi all, according to http://www.openbsd.org/faq/faq4.html#SpaceNeeded 250 MB for /usr is sufficient, in case X isn't installed on an OpenBSD system. My /usr partition (located on a 512 MB CompactFlash drive) recently has reached its limits after living through multiple releases (3.4 - 3.8). du -h: ... /dev/wd0e 359M311M 30.3M91%/usr folders in my /usr partition: bin 19.9M games 1.4M include 16.8M lib 100M libdata 76.8M libexec 2.6M lkm 2.0K local 10.8M mdec 220K obj - /home/obj ports - /home/ports sbin 15.9M share 62.6M src - /home/src My goal is to savely remove all files from older releases, which aren't needed anymore. At least in /usr/lib, there seem to be some directories, which exclusively contain files from older releases, namely /usr/lib/gcc-lib/i386-unknown-openbsd[release number]. Is it save to remove them after upgrading to a newer release? The content of /usr/libdata seems to be growing with each release, too. Which directories/files may be removed from /usr without risking too much? Is it better to wipe /usr and do a complete reinstall of all /usr content from a fresh OpenBSD system? regards, Andreas
Re: slightly OT: TCP checksum and RFC conformity
Hi, Damien Miller wrote: ... [EMAIL PROTECTED] djm]$ netstat -sp ip | grep -E '(bad.*checksum|total packets)' 61092730 total packets received 0 bad header checksums wouldn't netstat -sp tcp | grep -E '(bad.*checksum|total packets)' give the output of interest? (uptime 10 days on my slow ADSL link) netstat -sp ip | grep -E '(bad.*checksum|total packets)' 2448320 total packets received 0 bad header checksums netstat -sp tcp | grep -E '(bad.*checksum|total packets)' 23 discarded for bad checksums 0 bad/missing md5 checksums Doesn't this mean that 23 errors were not detected by the link layer (probably because the errors were introduced some hops away from me) and only the TCP checksum catched them? I hope you're right and it's not a reliability problem in practice. regards, Andreas
Re: slightly OT: TCP checksum and RFC conformity
Hi, Tobias Weingartner wrote: On Thursday, November 17, Andreas Bartelt wrote: As much better algorithms for error detection are known and PC performance (and also Internet traffic) has increased a lot since the introduction of TCP - do you think that the original checksum algorithm is still the best choice in terms of a reliability/performance tradeoff? Nope, it is not. But that's the reason it's called a standard. You get some good, and some bad with them. Welcome to the real world... it's probably my lack of knowledge, but I thought it would be possible to solve this by a TCP option without breaking interoperability. So this is actually a design decision which can't be corrected without a TCP replacement (which, I guess, won't happen in the next years)? regards, Andreas
slightly OT: TCP checksum and RFC conformity
Hi all, I was wondering why such a simple checksum algorithm is implemented in TCP. I suppose, it's because of the slow CPU performance many years ago. This algorithm looks so unreliable to me that it even can't protect against some pretty simple errors, which (I suppose) also could occur randomly (but obviously very seldomly in practice). In RFC 1122 I've read that the TCP checksum MUST (the usual caps lock problem...) be implemented: ... 4.2.2.7 TCP Checksum: RFC-793 Section 3.1 Unlike the UDP checksum (see Section 4.1.3.4), the TCP checksum is never optional. The sender MUST generate it and the receiver MUST check it. ... So I'm wondering why it MUST be calulated: is it necessary to implement a checksum in TCP because reliability at layer 2 is insufficient in practice? I see only two possible answers to this question: 1) yes - than it's a very old reliability bug and should be fixed, because sooner or later the TCP checksum won't catch a random error pattern in a segment. (should it be fixed by always using an alternate TCP checksum option, i.e. a MD5 hash? Or by improving layer 2 reliability in hardware?) [btw, netstat -sp tcp shows me that there sometimes are TCP checksum errors - 23 errors in 9 days on a slow DSL link] 2) no - so why not skip TCP checksum calculation at all? (at least for incoming seqments this wouldn't break a thing besides the RFC itself). I know that some new NICs do checksum calculation in hardware for performance reasons, but this has nothing to do with the actual problem (if there even is a necessity to calculate a checksum at transport layer). Please correct me if my assumptions or conclusions are wrong. regards, Andreas
Re: slightly OT: TCP checksum and RFC conformity
Hi, Ted Unangst wrote: ... good luck communicating with other tcp devices after you change your checksum to md5. the point is to be fast and catch some errors. also, type end-to-end into google. thanks for the interesting paper. I now understand why it makes sense to use a checksum at link layer which catches only most errors, because not all applications require full protection against random errors. I also understand that error detection/error correction is always a performance tradeoff, which also depends on the reliability requirements and the latency of the connection. As you know, TCP has been adapted to changing requirements in the past via TCP options, which also provide a fallback mechanism. RFC 1146 is about alternate TCP checksums (I don't know how good they are), but I've found no clues about actual implementations of them. Please tell me, did I just search at the wrong places? 2) no - so why not skip TCP checksum calculation at all? (at least for incoming seqments this wouldn't break a thing besides the RFC itself). because then you don't detect errors. That's exactly my point. My basic assumption was that the TCP checksum doesn't provide enough protection against random errors. By googling for 'crc tcp checksum disagree' I've found a paper which seems to confirm this. The tcp(4) man page says The TCP protocol provides a reliable, flow-controlled, two-way transmission of data. It doesn't say The TCP protocol provides a reliable, ..., only if shit doesn't happen. As much better algorithms for error detection are known and PC performance (and also Internet traffic) has increased a lot since the introduction of TCP - do you think that the original checksum algorithm is still the best choice in terms of a reliability/performance tradeoff? regards, Andreas
Re: OT: Compact Flash Longevity; was Re: dd image file to compact flash takes very long
Hi, Matt Garman wrote: ... Has anyone else out there been brave enough to go rw on their CF cards? Results? I'm using a 512 MB Sandisk Ultra II 24/7 in a home server for about 2 years now. No problems. I suppose power failures can be a problem with CompactFlash cards (don't know if it just was bad coincidence). Before the Ultra II I used a regular Sandisk 512 MB CompactFlash card, which broke when I had a power loss at home. Fortunately, Sandisk cards have a long warranty period :) regards, Andreas
