Re: usb wifi wpa2 enterprise

[Gerald Hanuer]

 On Sat, Sep 5, 2015 at 4:21 AM
 Shaun Reiger [srei...@sprmail.net] wrote:

 > Hi I'm trying to find out if obsd supports any usb wifi
 > adapters that can connect to a wpa2 enterprise network.
 > I have read through a couple driver man pages urtwn, iwn,
 > rsu..etc but can't determine if the adapters listed will
 > connect. Anyone with any experience in this would be helpful.

 Have a look at  Undeadly.org.
 A good high level view of set up.

 http://undeadly.org/cgi?action=article=20130128142215


 Gerald Hanuer

Re: Native EFI Bootloader Support

[Romain FABBRI]

Could help some people like me who have an asus t100 which only accept UEFI 
boot. (scarry)

-Message d'origine-
De : owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] De la part de Chris 
Cappuccio
Envoyé : vendredi 4 septembre 2015 20:23
À : Gerald Hanuer 
Cc : misc@openbsd.org
Objet : Re: Native EFI Bootloader Support

Gerald Hanuer [ghanuer497...@gmail.com] wrote:
>  Hello misc@,
> 
>  Native UEFI goes in tree.
>  http://marc.info/?l=openbsd-cvs=144115942223734=2
> .
>  Great work all.
> 
>  So what might the future hold for UEFI Secure Boot.
> 

So, the tree won't develop support for this standard until UEFI systems require 
it. Alternately, if someone writes it ahead of time, maybe that will be useful.
(Useful in making it easier to boot OpenBSD without disabling secure boot in 
your BIOS, or useful in allowing a vendor to lock their proprietary hardware to 
their own signed openBSD loader, etc...)

Since the purpose of Secure Boot provide little to no benefit to users (in fact 
quite the opposite), the question becomes why?

Chris

Re: usb wifi wpa2 enterprise

[Stefan Sperling]

On Sat, Sep 05, 2015 at 09:06:28AM +, Stuart Henderson wrote:
> The bigger challenge is accurately identifying a chipset before purchase,
> but they're pretty cheap so it isn't usually a big hardship if a particular
> device doesn't work.

And it's never a bad idea to offer unsupported devices to the OpenBSD
project as a hardware donation.

Re: issue with pf syntax parser

[Otto Moerbeek]

On Fri, Sep 04, 2015 at 07:43:35PM +0200, Joseph A Borg wrote:

> this is all very fascinating. Is it possible to contemplate a pre-filter that 
> chomps out trailing whitespace and comments? Would this overly complicate the 
> parsing process and introduce security issues?

Nah... you'll loose all line number info. And it is ugly,

-Otto
> 
> I???m asking because this might improve readability, usability and security 
> for less gifted users like me???
> 
> 
> > On 04 Sep 2015, at 19:37, Otto Moerbeek  wrote:
> > 
> > On Fri, Sep 04, 2015 at 05:51:54PM +0300, Kimmo Paasiala wrote:
> > 
> >> On Fri, Sep 4, 2015 at 4:02 PM, Joseph A Borg  wrote:
> >>> maybe the syntax error should point to the line where there are extra 
> >>> characters after the escape?
> >>> 
> >>> 
> >> 
> >> That would require making the backslash a lexical token in the
> >> pf.conf(5) syntax. Now it's just a simple escape character that gets
> >> eaten and forgotten by the lexical analyzer that splits the input into
> >> tokens to be parsed by the syntax parser.
> >> 
> >> -Kimmo
> > 
> > It's a historical accident that the pf grammar is line oriented. I
> > once started a litttle project to modify the pf yacc grammer to treat
> > end-of-lines as regular whitespace and came a long way, but something
> > got in between and the diff got lost
> > 
> > -Otto

Re: pf vs mp

[Stuart Henderson]

On 2015-09-02, Dot Yet  wrote:
> Any idea if running an ipsec vpn or openvpn on the same machine will
> benefit from the second core? working remotely over VPN is quite common
> these days. so all the extra juice may help encryption etc. is it so?

Using a processor that supports AESNI (it shows up in the cpu attach
lines in dmesg) and choosing ciphers that work with this (if you have
the choice) will have a much bigger effect than multiple cores.

> On Tue, Sep 1, 2015 at 8:59 PM, Quartz  wrote:
>
>> Maybe this webpage would help you make an informed choice?
>>>
>>> https://calomel.org/pf_config.html
>>>
>>
>> That looks like a good reference for setting up pf and the right way to
>> architect your pf.conf, but it doesn't appear to address any of the cpu
>> threading issues I'm trying to figure out. Thanks though, I'll keep a copy
>> of that in my files, it might help when we finally set this system up.

That really isn't a great reference. A huge chunk (of a very long page)
deals with things that almost nobody needs to touch, the things which
actually help laying out pf.conf nicely (like tags) are only lightly
dealt with, the "match log(matches)" which is indispensible when
debugging more complex rulesets isn't mentioned at all.

OpenBSD octeon on DSR-1000n

[Roberto Katalinic]

I have a Dlink DSR-1000N and want to install OpenBSD on it.

I saw the DSR-500 as a supported device on the octeon list and was hoping the
1000n would be as well.
I didn't get very far - "Error allocating memory for elf image!" when booting
the kernel.

Anyone knows if the 1000n is being worked on/supported?

Regards,
Roberto


Information contained in this e-mail is intended for the use of the addressee
only, and is confidential and may be the subject of Legal Professional
Privilege. Any dissemination, distribution, copying or use of this
communication without prior permission of the addressee is strictly
prohibited. The contents of an attachment to this e-mail may contain software
viruses which could damage your own computer system. While Kliker IT Services
Ltd. has taken every reasonable precaution to minimise this risk, we cannot
accept liability for any damage which you sustain as a result of software
viruses. You should carry out your own virus checks before opening the
attachment. Registered Office: New House, South Grove, Petworth, GU280ED.
Company Number: 8206089.Company Registered in England and Wales.

Re: Another working USB WiFi adapter:

[Stefan Sperling]

On Fri, Sep 04, 2015 at 02:52:19PM -0300, Henrique Lengler wrote:
> It has been difficult to me to figure out what causes this error, and
> try to reproduce it, it looks totally random, some days I get a lot of
> timeouts, others I get no one.

A "device timeout" means that an outgoing packet could not be transmitted
during a period of 5 seconds. Assuming the driver works correctly, what
you're seeing could simply be a matter of heavy contention for the medium.

How many other wifi networks are "active" around you when the timeout occurs?
Perhaps monitor traffic on your channel (from another box with a wireless
interface in monitor mode on the same channel) continously, and check if
bursts of traffic from other networks coincide with the athn device giving up.

Re: usb wifi wpa2 enterprise

[Stuart Henderson]

On 2015-09-05, Shaun Reiger  wrote:
> Hi I'm trying to find out if obsd supports any usb wifi adapters that can
> connect to a wpa2 enterprise network. I have read through a couple driver
> man pages urtwn, iwn, rsu..etc but can't determine if the adapters listed
> will connect. Anyone with any experience in this would be helpful.

See other replies too, but individual drivers where the manual mentions
support for WPA-PSK/WPA2-PSK should be good for WPA-enterprise with the
wpa_supplicant package.

The bigger challenge is accurately identifying a chipset before purchase,
but they're pretty cheap so it isn't usually a big hardship if a particular
device doesn't work.

Re: spamassasin large CPU usage on new snapshot and a huge bayes_toks file not reported in df

[Stuart Henderson]

On 2015-09-04, Adam Wolk  wrote:
> It's quite possible that Bayesian filtering started working for me only
> since this snapshot. I would appreciate it if you could check the size
> of your bayes_toks db & some info on general growth per email (seems to
> be around 30-60M on my server) as that's the only thing I think could
> be wrong with it atm. 65.3G accumulated in less than 24h for a DB that
> serves around 11k emails *per month* seems a lot (and most of that
> traffic are OpenBSD mailing lists).

That definitely seems wrong, my bayes_toks from 500-1000 mails/day with
amavis+spamassassin is around 5MB. I'm not sure where to start looking
though, I'd probably try wiping the db and starting again, though the
only time I remember having to do that myself is when someone was relaying
spam through a host in DNSWL which got auto-learned as ham (i.e bogus data
not corruption).

$ sudo -u _vscan sa-learn --dump magic
0.000  0  3  0  non-token data: bayes db version
0.000  0   4202  0  non-token data: nspam
0.000  0   1799  0  non-token data: nham
0.000  0 151022  0  non-token data: ntokens
0.000  0 1422052584  0  non-token data: oldest atime
0.000  0 1441425256  0  non-token data: newest atime
0.000  0 1441426503  0  non-token data: last journal sync atime
0.000  0 1441412100  0  non-token data: last expiry atime
0.000  0  0  0  non-token data: last expire atime delta
0.000  0  0  0  non-token data: last expire reduction 
count

Re: dmesg Intel NUC NUC5CPYH

[Tim Kuijsten]

Op 04-09-15 om 21:06 schreef Tim Kuijsten:

Op 04-09-15 om 21:01 schreef Ted Unangst:

Tim Kuijsten wrote:

tl;dr no network, dmesg for 5.7 release, 5.8 current mp and sp included.


With 5.7 release a dhcp response is received, but no other addresses
than the one that is assigned to the machine can be pinged (the dhcp
server is in the arp cache, but no ping reply is received from it).


jsg commited a fix for the ethernet earlier today.

the wifi won't be supported for some time though.



wow, that would be awesome! I'll test a new snapshot as soon as they
become available.

(this will be a small low power sftp server that won't use wifi anyway).


The network is idd functional now with the snapshot from today, super! 
Special thanks to jsg, tedu and brad, I will increase my 
number-of-openbsd-boxes donation multiplier. :)


I'll add another dmesg, sysctl hw.sensors and apm output of the mp 
kernel (still figuring out who is using the duplicate ip-address, I 
assume it's not a problem in the driver).


OpenBSD 5.8-current (GENERIC.MP) #1347: Sat Sep  5 01:11:49 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8489840640 (8096MB)
avail mem = 8228626432 (7847MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI LPIT 
CSRT SSDT
acpi0: wakeup devices PS2K(S3) PS2M(S3) XHC1(S4) HDEF(S4) PXSX(S4) 
RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) BRCM(S0) 
BRC1(S0) PWRB(S4)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) CPU N3050 @ 1.60GHz, 1600.40 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,

xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 80MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
cpu1 at mainbus0: apid 4 (application processor)
cpu1: Intel(R) Celeron(R) CPU N3050 @ 1.60GHz, 1600.00 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,

xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 2, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 115 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP02)
acpiprt3 at acpi0: bus 3 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpiec0 at acpi0: not present
acpicpu0 at acpi0
C2: state 6: substate 8 >= num 3
C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0
C2: state 6: substate 8 >= num 3
C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: CLK0, resource for CAMD
acpipwrres1 at acpi0: CLK0
acpipwrres2 at acpi0: CLK1, resource for CAM3
acpipwrres3 at acpi0: USBC, resource for XHC1
acpibat0 at acpi0: BAT0 not present
acpibat1 at acpi0: BAT1 not present
acpibat2 at acpi0: BAT2 not present
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
acpivideo0 at acpi0: GFX0
cpu0: Enhanced SpeedStep 1600 MHz: speeds: 1601, 1600, 1520, 1440, 1360, 
1280, 1200, 1120, 1040, 960, 880, 800, 720, 640, 560, 480 MHz

pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Braswell Host" rev 0x21
vga1 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x21
intagp at vga1 not configured
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ahci0 at pci0 dev 19 function 0 "Intel Braswell AHCI" rev 0x21: msi, 
AHCI 1.3.1

ahci0: port 0: 6.0Gb/s
ahci0: PHY offline on port 1
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct 
fixed naa.500a0751f0096edf

sd0: 238475MB, 512 bytes/sector, 488397168 sectors, thin
xhci0 at pci0 dev 20 function 0 "Intel Braswell xHCI" rev 0x21: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
"Intel Braswell SIO DMA" rev 0x21 at pci0 dev 24 function 0 not configured
"Intel Braswell SIO I2C" rev 0x21 at pci0 dev 24 function 6 not configured
"Intel Braswell SIO I2C" rev 0x21 at pci0 dev 24 function 7 not configured
"Intel Baswell TXE" rev 0x21 at pci0 dev 26 function 0 not configured
ppb0 at pci0 dev 28 function 0 "Intel Braswell PCIE" rev 0x21: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 "Intel Braswell 

Re: usb wifi wpa2 enterprise

[Shaun Reiger]

Thanks for the tips I will have to try these out when I'm back at
University next week. I noticed that in undeadly it didn't mention anything
about the certificates is that just added in the wpa_supplicant.conf
script. like this

ca_cert="/path/to/downloaded/cert"

Thanks



On Sat, Sep 5, 2015 at 3:25 AM, Stefan Sperling  wrote:

> On Sat, Sep 05, 2015 at 09:06:28AM +, Stuart Henderson wrote:
> > The bigger challenge is accurately identifying a chipset before purchase,
> > but they're pretty cheap so it isn't usually a big hardship if a
> particular
> > device doesn't work.
>
> And it's never a bad idea to offer unsupported devices to the OpenBSD
> project as a hardware donation.
>
>


-- 
Shaun

"Ars longa, vita brevis, occasio praeceps, experimentum periculosum,
iudicium difficile" - Hippocrates (c. 400BC)

Re: Spamd TLS and exchange

[Kevin Chadwick]

> except as ip disconnected after 19 seconds
oops 3 seconds... I have -s 3 spamd flag

Anyone else receiving from microsoft, maybe it's a configuration
combination such as a timeout only applied to TLS by microsoft but I
would have thought the same TCP would just be encapsulated and behave
exactly the same?

I'll test the defaults except TLS anyway and if no success just
disable TLS.

-- 

KISSIS - Keep It Simple So It's Securable

Re: issue with pf syntax parser

[Benny Lofgren]

On 2015-09-04 14:30, Joseph A Borg wrote:
> I have something like this in pf.conf:
> 
> services  = "{ 
>   ssh,
> \
>   http, https, 8000, 
> 8080, 8088,  \
>   smtp, pop3, pop3s, 
> imap, imaps, \
>   submission, 465,
> \
>   domain, ntp 
> \
>   }"
> 
> if there’s white space after the back slash the parser barfs by not creating 
> the macro and then raising an error when it’s first used.
> 
> I would assume this to be an inconvenience for the user as it’s not always 
> possible to check whitespace after the backslash


Everyone who commented so far seem to have missed the obvious - you
don't NEED to escape the newline in this case. The parser handles this
case just fine without them:

paddan:/etc# cat /tmp/tstpf.conf
services = "{
ssh,
http, https, 8000, 8080, 8088,
smtp, pop3, pop3s, imap, imaps,
submission, 465,
domain, ntp
}"

block in proto tcp from any to any port $services

paddan:/etc# pfctl -f /tmp/tstpf.conf
paddan:/etc# pfctl -s rules
block drop in proto tcp from any to any port = 22
block drop in proto tcp from any to any port = 80
block drop in proto tcp from any to any port = 443
block drop in proto tcp from any to any port = 8000
block drop in proto tcp from any to any port = 8080
block drop in proto tcp from any to any port = 8088
block drop in proto tcp from any to any port = 25
block drop in proto tcp from any to any port = 110
block drop in proto tcp from any to any port = 995
block drop in proto tcp from any to any port = 143
block drop in proto tcp from any to any port = 993
block drop in proto tcp from any to any port = 587
block drop in proto tcp from any to any port = 465
block drop in proto tcp from any to any port = 53
block drop in proto tcp from any to any port = 123
paddan:/etc# _


Regards,
/Benny

top(1), ps(1): per-process CPU time accounting wrong?

[Timo Buhrmester]

On -current amd64 (GENERIC and GENERIC.MP), per-process CPU time accounting 
seems wrong to me, judging from watching top(1) and ps(1) while compiling stuff.

The system is under load, building an OpenBSD release, but top(1) and ps(1) 
look like there's not much going on:
Most of the time, top(1) (with idle processes hidden) shows the load and CPU 
usage, but no processes that are actually consuming the CPU time:
| load averages:  2.97,  2.06,  1.66 flap.localdomain 
23:47:04
| 38 processes: 36 idle, 2 on processor
| CPU0 states: 50.7% user,  0.0% nice, 15.4% system,  0.2% interrupt, 33.7% idle
| CPU1 states: 34.1% user,  0.0% nice,  9.4% system,  0.0% interrupt, 56.5% idle
| Memory: Real: 36M/1127M act/tot Free: 2088M Cache: 643M Swap: 0K/2224M
| 
|   PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND


Occasionally the pertinent programs do show up, but with *very* little apparent 
CPU usage:
| load averages:  2.87,  2.00,  1.63 flap.localdomain 
23:47:19
| 38 processes: 36 idle, 2 on processor
| CPU0 states: 60.0% user,  0.0% nice,  0.0% system,  0.0% interrupt, 40.0% idle
| CPU1 states: 42.3% user,  0.0% nice,  0.0% system,  0.0% interrupt, 57.7% idle
| Memory: Real: 49M/1139M act/tot Free: 2077M Cache: 643M Swap: 0K/2224M
| 
|   PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
| 11425 root  640   19M   20M onproc- 0:00  0.29% cc1
| 14278 root  -60 4380K 5172K sleep piperd0:00  0.10% as
|  7894 root  180 2268K 4388K sleep pause 0:01  0.05% make
| 19935 root  100  528K 1492K sleep wait  0:00  0.05% cc



ps aux seems to get it wrong, too:
| # ps aux
| USER   PID %CPU %MEM   VSZ   RSS TT  STAT  STARTED   TIME COMMAND
| [...]
| root 19561  0.0  0.0   836   904 p0  Is11:03PM0:00.18 -ksh (ksh)
| root 11801  0.0  0.1   764  1700 p0  I+11:40PM0:00.01 make release
| root  7894  0.1  0.1  2296   p0  S+11:44PM0:00.65 make
| root 22634  0.0  0.0   628   696 p0  S+11:47PM0:00.00 /bin/sh -ec 
cc [...]
| root  2566  0.8  0.5 18672 18556 p0  R+11:47PM0:00.37 
/usr/lib/gcc-lib/amd64-unknown-openbsd5.8/4.2.1/cc1 [...]
| root 30930  0.0  0.0   524  1484 p0  S+11:47PM0:00.00 cc [...]
| root 16823  0.0  0.2  4384  5176 p0  S+11:47PM0:00.01 as -Qy -o 
trees.o -
| [...]


ps axl does show at least some `short term' usage:
| # ps axl 
|   UID   PID  PPID CPU PRI  NI   VSZ   RSS WCHAN   STAT  TT   TIME COMMAND
| [...]
| 0 19561 14740   0  18   0   836   904 pause   Isp00:00.18 -ksh 
(ksh)
| 0 11801 19561  27  18   0   764  1700 pause   I+p00:00.01 make 
release
| 0  7894 11801  36  18   0  2340  4520 pause   S+p00:00.89 make
| 0   621 21260  36  10   0   528  1476 waitS+p00:00.00 cc [...]
| 0 21260  7894  36  18   0   624   688 pause   S+p00:00.00 /bin/sh 
-ec cc  [...]
| 0  9291   621  36  64   0 11944 12180 -   R+p00:00.07 
/usr/lib/gcc-lib/amd64-unknown-openbsd5.8/4.2.1/cc1 [...]
| 0  5156   621  36  -6   0  4388  5140 piperd  S+p00:00.01 as -Qy 
-o uhci_pci.o -
| [...]


Any idea as for what's happening here?  Or is this as-expected an I'm 
misinterpreting the values?


Cheers,
Timo Buhrmester


PS: Attached the output of dmesg(8) just in case it matters
# dmesg
OpenBSD 5.8-current (GENERIC.MP) #0: Sat Sep  5 23:00:31 CEST 2015
fstd@flap.localdomain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3472392192 (3311MB)
avail mem = 3363315712 (3207MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMX ECDT DBGP BOOT OEMB HPET SSDT
acpi0: wakeup devices SBAZ(S4) P0PC(S4) OHC0(S4) OHC1(S4) EHC0(S4) OHC2(S4) 
OHC3(S4) EHC1(S4) OHC4(S4) PCE2(S4) PCE5(S4) GLAN(S4) PCE6(S4) PCE7(S4) 
PWRB(S4) SLPB(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) II Dual-Core M300, 2001.03 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,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,3DNOWP,OSVW,IBS,SKINIT,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu0: AMD erratum 721 detected and fixed
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Athlon(tm) II Dual-Core M300, 2000.06 

Re: Native EFI Bootloader Support

[Ryan McBride]

On Fri, Sep 04, 2015 at 11:22:48AM -0700, Chris Cappuccio wrote:
> Since the purpose of Secure Boot provide little to no benefit to users
> (in fact quite the opposite), the question becomes why?   
>   

For paranoid softraid crypto users who are concerned about a modified
bootloader leaking their softraid key. 

Re: top(1), ps(1): per-process CPU time accounting wrong?

[Michael McConville]

Timo Buhrmester wrote:
> On -current amd64 (GENERIC and GENERIC.MP), per-process CPU time
> accounting seems wrong to me, judging from watching top(1) and ps(1)
> while compiling stuff.
> 
> The system is under load, building an OpenBSD release, but top(1) and
> ps(1) look like there's not much going on: Most of the time, top(1)
> (with idle processes hidden) shows the load and CPU usage, but no
> processes that are actually consuming the CPU time:
> | load averages:  2.97,  2.06,  1.66 flap.localdomain 
> 23:47:04
> | 38 processes: 36 idle, 2 on processor
> | CPU0 states: 50.7% user,  0.0% nice, 15.4% system,  0.2% interrupt, 33.7% 
> idle
> | CPU1 states: 34.1% user,  0.0% nice,  9.4% system,  0.0% interrupt, 56.5% 
> idle
> | Memory: Real: 36M/1127M act/tot Free: 2088M Cache: 643M Swap: 0K/2224M
> | 
> |   PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND

There's just over one core being consumed here. If there's one hungry
single-threaded process, its load can appear split between multiple
cores because it gets context switched a bunch of times in each sampling
interval.

httpd

[frcc]

Swapped over from Apache to httpd recently.
Nice simple, easy to set-up httpd.conf file.
The system works very well with our virtual 
static sites.

Thanks Developers

:)