Re: dmesg: notebook hp pavilion dm3 1110eg 13.3"

[Marcus MERIGHI]

mlar...@azathoth.net (Mike Larkin), 2015.12.15 (Tue) 23:25 (CET):
> On Tue, Dec 15, 2015 at 10:14:23AM +0100, Marcus MERIGHI wrote:
> > CCing misc@ because there's no public access to dmesg@.
> > 
> > BIOS: older machine, nothing fancy
> > Xwin: works, incl. touchpad
> > Suspend: works without Xwin only
> > Resume: does not work, regardless of Xwin
> 
> I love these reports that attempt to use the fewest words possible.
> It's like taking your car to the mechanic and saying "does not work",

not meant that way. posted to dmesg@ and:
> CCing misc@ because there's no public access to dmesg@.

these are machines I have access to for a short time only and I thought
dmesgs were welcome. stopping the noise.

marcus

> and letting
> them try to figure out what exactly is broken, without providing any
> symptoms or other explanation.
> 
> -ml
> 
> > WLAN: works. fw_update fetched firmware for athn0 via athn0
> > 
> > dmesg, X.org.log, pcidump, usbdevs, sysctl hw, ifconfig, xdpyinfo,
> > xrandr, product specs below.
> > 
> > OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > RTC BIOS diagnostic error 80
> > real mem = 2931224576 (2795MB)
> > avail mem = 2838556672 (2707MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe9260 (27 entries)
> > bios0: vendor Insyde Corp. version "F.29" date 06/09/2010
> > bios0: Hewlett-Packard HP Pavilion dm3 Notebook PC
> > acpi0 at bios0: rev 2
> > acpi0: sleep states S0 S3 S4 S5
> > acpi0: tables DSDT FACP HPET APIC MCFG BOOT SLIC SSDT
> > acpi0: wakeup devices SLPB(S3) LID_(S3) PB2_(S4) PB4_(S5) PB5_(S4) PB6_(S5) 
> > PB7_(S4) PB9_(S5) PB10(S5) AZAL(S3) USB0(S3) USB1(S3) USB5(S3) P2P_(S5)
> > 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 Athlon(tm) Neo X2 Dual Core Processor L335, 1596.22 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,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
> > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 256KB 
> > 64b/line 16-way L2 cache
> > cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> > cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
> > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> > cpu0: apic clock running at 199MHz
> > cpu1 at mainbus0: apid 1 (application processor)
> > cpu1: AMD Athlon(tm) Neo X2 Dual Core Processor L335, 1595.95 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,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
> > cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 256KB 
> > 64b/line 16-way L2 cache
> > cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> > cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
> > ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins
> > ioapic0: misconfigured as apic 0, remapped to apid 4
> > acpimcfg0 at acpi0 addr 0xf700, bus 0-15
> > acpiprt0 at acpi0: bus 0 (PCI0)
> > acpiprt1 at acpi0: bus 1 (AGP_)
> > acpiprt2 at acpi0: bus 2 (PB2_)
> > acpiprt3 at acpi0: bus 3 (PB4_)
> > acpiprt4 at acpi0: bus 9 (PB5_)
> > acpiprt5 at acpi0: bus -1 (PB6_)
> > acpiprt6 at acpi0: bus -1 (PB7_)
> > acpiprt7 at acpi0: bus -1 (PB9_)
> > acpiprt8 at acpi0: bus -1 (PB10)
> > acpiprt9 at acpi0: bus 10 (P2P_)
> > acpiec0 at acpi0
> > acpicpu0 at acpi0: C1(@1 halt!), PSS
> > acpicpu1 at acpi0: C1(@1 halt!), PSS
> > acpitz0 at acpi0: critical temperature is 100 degC
> > acpibtn0 at acpi0: PWRB
> > acpibtn1 at acpi0: SLPB
> > acpibtn2 at acpi0: LID_
> > acpiac0 at acpi0: AC unit offline
> > acpibat0 at acpi0: BAT0 model "5160" serial Li4402A type Li oem " 
> > Hewlett-Packard "
> > acpivideo0 at acpi0: VGA_
> > acpivideo1 at acpi0: VGA_
> > cpu0: PowerNow! K8 1596 MHz: speeds: 1600 800 MHz
> > pci0 at mainbus0 bus 0
> > pchb0 at pci0 dev 0 function 0 "AMD RS780 Host" rev 0x00
> > ppb0 at pci0 dev 1 function 0 "AMD RS780 PCIE" rev 0x00
> > pci1 at ppb0 bus 1
> > radeondrm0 at pci1 dev 5 function 0 "ATI Radeon HD 3200" rev 0x00
> > drm0 at radeondrm0
> > radeondrm0: apic 4 int 18
> > ppb1 at pci0 dev 2 function 0 "AMD RS780 PCIE" rev 0x00: msi
> > pci2 at ppb1 bus 2
> > radeondrm1 at pci2 dev 0 function 0 "ATI Mobility Radeon HD 4300" rev 0x00
> > drm1 at radeondrm1
> > radeondrm1: msi
> > azalia0 at pci2 dev 0 function 1 "ATI Radeon HD 4000 HD Audio" rev 0x00: msi
> > azalia0: no supported codecs
> > ppb2 at pci0 dev 4 function 0 "AMD RS780 PCIE" rev 0x00: msi
> > pci3 at ppb2 bus 3
> > 3:0:0: mem address conflict 0xfffe/0x2
> > re0 

dpb build box performance suggestions.

[Christopher Sean Hilton]

I'm trying to dpb to maintain a small set of packages for a handfull
of OpenBSD boxes that I run. These boxes will all be single purpose
servers of some type or another. Many of them will run with limited
disk space and memory on Soekris hardware. What resources do I want on
my dpb/build box to make it fast?

My dpb/build box is a VMWare virtual machine on a host with SSD
storage. Tweaking the number of available CPU's, the memory, or the
type of storage is relatively simple further, I can split the task and
have a fast build VM and an install virtual machine which shares httpd
available storage via NFS.

Thanks in advance for any help/advice.

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

Re: Memory exhaustion

[Peter N. M. Hansteen]

On 12/16/15 15:52, Steve Shockley wrote:

I recently ran into an issue with my OpenBSD mail server where it would
die every day around 5 AM.  With 5.7-stable it would just become
unresponsive, with 5.8-stable it would print "scsi_xfer pool exhausted"
repeatedly on the console.  It turned out to be SpamAsssassin sa-learn
running on a folder with 26k+ messages, and I simply ran out of memory
and swap.


Have those messages accumulated over some time, or do you receive that 
number of messages within a very short time frame?


I'm asking because unless I remember this incorrectly, there's no need 
to have sa-learn run more than once on any given message (the tokenized 
form is stored in the /var/db/spamassassin/bayes hierarchy). If you have 
a cron job or similar running sa-learn, it's likely useful have the 
scrimp move already scanned messages off to somewhere out of the way or 
remove them entirely.


That said, while I haven't had spamassassin chrash machines yet, I've 
occasionally seen spamassassin's perl processes consume 100% cpu for 
long periods on slow machines, leading to spamassassin timeouts and 
delayed delivery. Emptying out the sa-learn input directories usually 
helps, and of course some version of throwing more or faster hardware at 
the problem might also help.


--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: dpb build box performance suggestions.

[Tati Chevron]

On Wed, Dec 16, 2015 at 01:01:51PM -0500, Christopher Sean Hilton wrote:

I'm trying to dpb to maintain a small set of packages for a handfull
of OpenBSD boxes that I run. These boxes will all be single purpose
servers of some type or another. Many of them will run with limited
disk space and memory on Soekris hardware. What resources do I want on
my dpb/build box to make it fast?


What do you mean by, 'fast'?

Our couple of build machines are both fairly standard core i5 boxes with
16 gb of RAM, and Corsair SSDs.  The RAM seems to make more difference
than anything else, because you can set the work directory to a ramdisk,
and do the entire build without touching the disk.

I wrote a short paper on tweaking the ports build system here:

http://www.gotati.com/papers/customising_openbsd_ports.html


My dpb/build box is a VMWare virtual machine on a host with SSD
storage. Tweaking the number of available CPU's, the memory, or the
type of storage is relatively simple


It's probably best to experiment and see what works best for your workload.
Much depends on the specific ports you are building, whether they will
benefit most from RAM or CPU, for example.

Also, be aware that some ports have a mass of unnecessary dependencies,
and that tweaking this can reduce the build time substantially, especially
if you are building the same packages repeatedly for some reason.

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: dpb build box performance suggestions.

[Christian Weisgerber]

On 2015-12-16, Christopher Sean Hilton  wrote:

> I'm trying to dpb to maintain a small set of packages for a handfull
> of OpenBSD boxes that I run. These boxes will all be single purpose
> servers of some type or another. Many of them will run with limited
> disk space and memory on Soekris hardware. What resources do I want on
> my dpb/build box to make it fast?

I wouldn't overthink it.

The number one limit is CPU.  Faster CPU, better.

Regarding memory, you want to avoid going into swap.  On amd64, the
biggest pig in the build is lang/pypy which requires ~4GB.  The
second biggest ones are the Mozillas, which take ~2GB during linking.
(binutils 2.17 may have shaved off a few hundred MB there, I haven't
really payed attention.)  The vast majority of ports take far, far
less memory.  So your memory requirements really depend on how many
of those big ports you will end up building in parallel.  With
ncpu*2GB but a minimum of 4GB you should be on the safe side.

Disk doesn't matter much.  If you run off magnetic disk, you want
to use soft updates at least for the work and log directories.

Probably the biggest question is how many cores to use for the
build.  At the low level, our SMP scales poorly.  More cores are
faster than fewer cores, but also mean that ever more CPU goes into
spinning on the big lock instead of compiling.  At the high level,
dpb's ability to distribute build jobs to all cores is limited by
the numer of ports and their interdependencies.  It works well for
building the whole ports tree, but if you only do a "small set of
packages", the build may have to wait for some port that everything
else depends on.

Probably the biggest hint for building small sets of packages on
more than one core is to increase dpb's parallel property (-p flag)
to ncpu, from its default of ncpu/2, so you won't see half the cores
idling while the build blocks on something like gcc/4.9 or llvm.

Anyway, as I said above, don't overthink it.  Do an initial build
with modest resources, see how it goes.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: dpb build box performance suggestions.

[Christian Weisgerber]

On 2015-12-16, Tati Chevron  wrote:

> Our couple of build machines are both fairly standard core i5 boxes with
> 16 gb of RAM, and Corsair SSDs.  The RAM seems to make more difference
> than anything else, because you can set the work directory to a ramdisk,
> and do the entire build without touching the disk.

Have you done actual comparisons?  With SSDs, I don't expect a
significant difference.  (There is none for doing a "make build"
of the base system.)

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: iwm(4) 11n support: it just works

[edward wandasiewicz]

Works nicely on the Chrombook Pixel 2015 i7.

Thanks for the update Peter.

$ dmesg

OpenBSD 5.8-current (GENERIC.MP) #1749: Wed Dec 16 01:22:42 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17094049792 (16302MB)
avail mem = 16571850752 (15804MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7ce42020 (9 entries)
bios0: vendor coreboot version "(null)" date 04/02/2015
bios0: GOOGLE Samus
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S2 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG SSDT
acpi0: wakeup devices HDEF(S3) WLAN(S3) EHCI(S3) XHCI(S3) ATPA(S3)
CODC(S3) LID0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz, 2408.62 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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-5500U CPU @ 2.40GHz, 2893.30 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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 3 (application processor)
cpu2: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz, 2893.31 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 1, package 0
cpu3 at mainbus0: apid 2 (application processor)
cpu3: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz, 2893.30 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FS
GSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0 addr 0xf000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus -1 (RP02)
acpiprt3 at acpi0: bus -1 (RP03)
acpiprt4 at acpi0: bus -1 (RP04)
acpiprt5 at acpi0: bus -1 (RP05)
acpiprt6 at acpi0: bus -1 (RP06)
acpiprt7 at acpi0: bus -1 (RP07)
acpiprt8 at acpi0: bus -1 (RP08)
acpiec0 at acpi0
acpicpu0 at acpi0: C3(700@148 mwait.1@0x33), C2(900@67 mwait.1@0x10),
C1(1000@0 mwait.1@0x1), PSS
acpicpu1 at acpi0: C3(700@148 mwait.1@0x33), C2(900@67 mwait.1@0x10),
C1(1000@0 mwait.1@0x1), PSS
acpicpu2 at acpi0: C3(700@148 mwait.1@0x33), C2(900@67 mwait.1@0x10),
C1(1000@0 mwait.1@0x1), PSS
acpicpu3 at acpi0: C3(700@148 mwait.1@0x33), C2(900@67 mwait.1@0x10),
C1(1000@0 mwait.1@0x1), PSS
acpitz0 at acpi0: critical temperature is 104 degC
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model "3487041" serial 809777200 type LION oem
"21484737139854675"
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
cpu0: Enhanced SpeedStep 2408 MHz: speeds: 2401, 2400, 1700, 1300, 900, 500
MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 5G Host" rev 0x09
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 5500" rev 0x09
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 2560x1700
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
azalia0 at pci0 dev 3 function 0 "Intel Core 5G HD Audio" rev 0x09: msi
xhci0 at pci0 dev 20 function 0 "Intel 9 Series xHCI" rev 0x03: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
ppb0 at pci0 dev 28 function 0 "Intel 9 Series PCIE" rev 0xe3
pci1 at ppb0 bus 1
iwm0 at pci1 dev 0 function 0 

Re: dpb build box performance suggestions.

[Michael McConville]

Christian Weisgerber wrote:
> On 2015-12-16, Tati Chevron  wrote:
> 
> > Our couple of build machines are both fairly standard core i5 boxes
> > with 16 gb of RAM, and Corsair SSDs.  The RAM seems to make more
> > difference than anything else, because you can set the work
> > directory to a ramdisk, and do the entire build without touching the
> > disk.
> 
> Have you done actual comparisons?  With SSDs, I don't expect a
> significant difference.  (There is none for doing a "make build" of
> the base system.)

FWIW: A few days ago, we added additional zeroing to tmpfs and were
discussing its performance. Another dev mentioned that their SSD is
already typically faster than tmpfs.

Re: dpb build box performance suggestions.

[Tati Chevron]

On Wed, Dec 16, 2015 at 06:00:10PM -0500, Michael McConville wrote:

Christian Weisgerber wrote:

On 2015-12-16, Tati Chevron  wrote:

> Our couple of build machines are both fairly standard core i5 boxes
> with 16 gb of RAM, and Corsair SSDs.  The RAM seems to make more
> difference than anything else, because you can set the work
> directory to a ramdisk, and do the entire build without touching the
> disk.

Have you done actual comparisons?  With SSDs, I don't expect a
significant difference.  (There is none for doing a "make build" of
the base system.)


FWIW: A few days ago, we added additional zeroing to tmpfs and were
discussing its performance. Another dev mentioned that their SSD is
already typically faster than tmpfs.


We have WRKOBJDIR on an 8 GB MFS partition, that uses half of the 16 GB
installed RAM.

An observation: we are not running a GENERIC kernel on these boxes, so
results will be skewed.  In addition, one of the build machines is
running with softraid crypto on all of it's mounted filesystems.  This
is for no reason other than to stress the softraid code.

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

iwm(4) 11n support: it just works

[Peter N. M. Hansteen]

For those not following tech@ or the commits closely, it might be nice 
to know that 11n support is arriving, as far as I can tell complete in 
iwm(4) - common in recent laptop models such as 2014 onwards thinkpads 
and others such as my noname (clevo). Next up the older iwn(4), also 
common in a lot of laptops out there but possibly more in the slightly 
older ones such as the one mentioned in my old piece[1]


Case in point, with a simple /etc/hostname.iwm0

nwid we_see_all_your_naughty_bits wpakey alltomorrowsparties[2]

the resulting config becomes

[Wed Dec 16 22:31:42] peter@elke:~$ ifconfig iwm0
iwm0: flags=208843 mtu 
1500

lladdr a0:a8:cd:63:ab:b9
priority: 4
groups: wlan egress
media: IEEE802.11 autoselect (HT-MCS6 mode 11n)
status: active
ieee80211: nwid we_see_all_your_naughty_bits chan 36 bssid 
e0:3f:49:23:bb:2c 35% wpakey  wpaprotos wpa1,wpa2 wpaakms 
psk wpaciphers tkip,ccmp wpagroupcipher tkip

inet 192.168.1.95 netmask 0xff00 broadcast 192.168.1.255
inet6 fe80::a2a8:cdff:fe63:abb9%iwm0 prefixlen 64 scopeid 0x1

Meaning if you have a reasonably recent laptop with something that looks 
similar to what 'man iwm' tells you is supported and an 11n access point 
within reach, *now* is a good time to see what the new code is good for.


Enjoy!

[1] http://bsdly.blogspot.no/2010/01/goodness-of-men-and-machinery.html
[2] no, not really but you can dream

appendix: dmesg from the latest snapshot -
OpenBSD 5.8-current (GENERIC.MP) #1749: Wed Dec 16 01:22:42 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17046183936 (16256MB)
avail mem = 16525438976 (15759MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb500 (35 entries)
bios0: vendor American Megatrends Inc. version "4.6.5" date 11/21/2013
bios0: Notebook W840SU Series
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT ASF! SSDT SSDT SSDT MCFG HPET SSDT 
SSDT DMAR CSRT
acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) 
RP03(S4) PXSX(S4) RP04(S4) RLAN(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) Core(TM) i7-4510U CPU @ 2.00GHz, 2793.94 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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 2 (application processor)
cpu1: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz, 2793.53 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT

cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz, 2793.53 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT

cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz, 2793.53 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP03)
acpiprt3 at acpi0: bus 3 (RP04)
acpiprt4 at acpi0: bus -1 (P0P2)
acpiprt5 at acpi0: bus -1 (P0PA)
acpiprt6 

Re: dpb build box performance suggestions.

[lists]

On Wed, 16 Dec 2015 18:58:48 + Tati Chevron 
wrote:

> On Wed, Dec 16, 2015 at 01:01:51PM -0500, Christopher Sean Hilton wrote:
> >I'm trying to dpb to maintain a small set of packages for a handfull
> >of OpenBSD boxes that I run. These boxes will all be single purpose
> >servers of some type or another. Many of them will run with limited
> >disk space and memory on Soekris hardware. What resources do I want on
> >my dpb/build box to make it fast?  
> 
> What do you mean by, 'fast'?

The dictionary antonym of slow.  What do you mean by mean?

> Our couple of build machines are both fairly standard core i5 boxes with
> 16 gb of RAM, and Corsair SSDs.

This season the sweet spot goes towards i7 4770 / 4790 with 32 GB RAM.
The logic behind this is the fastest desktop CPU for around $300-$350
price point with as much RAM as it can hold.  DDR4 is not mainstream,
yet, and this goes for some time.  As for storage, the lowest size of
Intel 3500 / 3510 SSDs and the 2-3 GB HGST HDDs, both 1x per system.
No RAID, or just pass-through.  You can spare the SSD cost, but don't
use silly gamer/enthusiast desktop class jagged metal style covered
parts that hide a flaky controller board (go for the Data Centre
optimised versions from Intel, really discard advice from gamers).
Don't forget 12 cm fans and a reliable 350-400 W PSU (cheap and almost
OK goes for Seasonic), and have a cold standby PSU unit just in case.
Oh yes, pick a Supermicro motherboard with a dedicated IPMI LAN port,
you'll find use for it.

> The RAM seems to make more difference than anything else, because you
> can set the work directory to a ramdisk, and do the entire build
> without touching the disk.

Nice point.
 
> I wrote a short paper on tweaking the ports build system here:
> 
> http://www.gotati.com/papers/customising_openbsd_ports.html
> 
> >My dpb/build box is a VMWare virtual machine on a host with SSD
> >storage. Tweaking the number of available CPU's, the memory, or the
> >type of storage is relatively simple  
> 
> It's probably best to experiment and see what works best for your workload.
> Much depends on the specific ports you are building, whether they will
> benefit most from RAM or CPU, for example.

Or both.  Drop VMWare on the floor NOW, if you need virtualisation use
generic QEMU/KVM in any recent Linux distribution of your choice and
plan to wipe it clean after you're done fiddling with it.  Yes, really
seriously remove the virtualisation for a build machine, go bare metal.
Try without hyperthreading for a comparison.  Before you notice and get
to complain you need VM for something just use the native OpenBSD
hypervisor.

> Also, be aware that some ports have a mass of unnecessary dependencies,
> and that tweaking this can reduce the build time substantially, especially
> if you are building the same packages repeatedly for some reason.

Use a "virtual" axe ;-) virtually "axing" around.

mupdf / mutool

[Stefan Wollny]

Hi there!

I like mupdf for it's speed with large documents (800+ pages and more). 
BUT: My usual workflow has it that I need to make printouts of specific 
pages from those PDFS, sometimes even print the entire document for 
legal reasons.

Anyone around who knows how to achieve this with mupdf/mutool? The man 
pages for mupdf/mutool do not provide any hints on this and 'startpage' 
(=google-proxy) didn't come up with anything but "no printing". (I use 
xpdf again as I do not want to open the doc a second time with xpdf only 
for printing.)

TIA.

Best,
STEFAN

Re: dpb build box performance suggestions.

[Tati Chevron]

Or both.  Drop VMWare on the floor NOW, if you need virtualisation use
generic QEMU/KVM in any recent Linux distribution of your choice and
plan to wipe it clean after you're done fiddling with it.  Yes, really
seriously remove the virtualisation for a build machine, go bare metal.
Try without hyperthreading for a comparison.  Before you notice and get
to complain you need VM for something just use the native OpenBSD
hypervisor.


Our build machines both run on bare metal.  To be honest, once you've
pulled the entire set of source distfiles for one release, you don't even
need much in the way of connectivity to stay up to date.


From the way the OP described the setup, it does look like he intends to

run the build machine remotely, as a VPS.  I wouldn't recommend using a
VPS as a build machine, as you need CPU and RAM with little connectivity,
which is the opposite of what most VPS providers will offer.  Our build
machines are on-site, and we just send the resulting binary packages
wherever they need to go.


Also, be aware that some ports have a mass of unnecessary dependencies,
and that tweaking this can reduce the build time substantially, especially
if you are building the same packages repeatedly for some reason.


Use a "virtual" axe ;-) virtually "axing" around.


Really, have a look at the dependencies for ImageMagick, and ask yourself
who really uses djvu, for example.  Removing it and ghostscript reduces
the dependencies from:

5.8-release:

# make print-build-depends

This port requires package(s) "bzip2-1.0.6p1 libusb1-1.0.9p9 lynx-2.8.9pl6
gmp-5.0.2p3 jbigkit-2.1 metaauto-1.0p1 autoconf-2.13p3 libelf-0.8.13p3
xz-5.2.1 png-1.6.17 help2man-1.47.1 autoconf-2.69p1 libffi-3.1p0
automake-1.14.1 automake-1.11.6p1 autoconf-2.63p0 autoconf-2.67p0
libltdl-2.4.2p1 libtool-2.4.2p0 hicolor-icon-theme-0.15
p5-XML-NamespaceSupport-1.11p0 p5-XML-SAX-0.96p1 giflib-5.1.1 imake-cf-1.0.5
imake-1.0.7 jpeg-9a tiff-4.0.4 lcms2-2.6p1 libwebp-0.4.3 libwmf-0.2.8.4p3
libiconv-1.14p3 gettext-0.19.5.1 gettext-tools-0.19.5.1 gmake-4.1p0
gnugetopt-1.1.6 libpaper-1.1.24.4 libnettle-3.1.1 icu4c-55.1p0 nspr-4.10.8
fftw3-common-3.2.2p1 fftw3-3.2.2p3 bash-4.3.39p0 libgpg-error-1.19
libgcrypt-1.6.3 libidn-1.32 curl-7.43.0 re2c-0.14.3 unzip-6.0p7
jasper-1.900.1p2 iso8879-1986p0 docbook-dsssl-1.79 ghostscript-fonts-8.11p3
p5-XML-Parser-2.44 xmltoman-0.4 intltool-0.51.0p0 pcre-8.37p1 libtasn1-4.5
p11-kit-0.22.1p1 gnutls-3.3.16 groff-1.22.3p2 gdbm-1.11p0 tcl-8.5.18 tk-8.5.18
ijs-0.35p2 libsigsegv-2.10p2 m4-1.4.17 bison-2.3p2 db-4.6.21p1v0 python-2.7.10
libxml-2.9.2p1 netpbm-10.35.96 docbook-4.5p1 jbig2dec-0.11 libxml-2.9.2p1
py-libxml-2.9.2p0 libxslt-1.1.28p2 docbook-xsl-1.68.1p5 xmlto-0.0.26p0
dbus-1.8.20v0 glib2-2.44.1 vala-0.28.0 dconf-0.24.0p1 shared-mime-info-1.4
libcroco-0.6.8p2 dbus-glib-0.104p0v0 dbus-1.8.20v0
dbus-daemon-launch-helper-1.8.20 docbook2x-0.8.8p1 py-setuptools-3.4.4p2v0
py-MarkupSafe-0.23 py-jinja2-2.7.3p0 py-tz-2015.4 py-babel-1.3p2
py-pygments-2.0.1 py-docutils-0.12 py-sphinx-1.2.3p0 py-crypto-2.6.1p0
py-beaker-1.6.2p3 py-mako-0.9.1p1 ninja-1.5.3p0 scons-2.3.5p0 jsoncpp-0.10.5
mozjs17-17.0p2 lzo2-2.09 cairo-1.14.2 gobject-introspection-1.44.0
gdk-pixbuf-2.30.8p1 atk-2.16.0 at-spi2-core-2.16.0p0 at-spi2-atk-2.16.0p0
polkit-0.113p3 consolekit-0.4.6p14 colord-1.2.11 json-glib-1.0.4
gsettings-desktop-schemas-3.16.1 libarchive-3.1.2 cmake-3.2.3p1
graphite2-1.2.4p0 harfbuzz-1.0.1 pango-1.36.8 librsvg-2.40.9 libproxy-0.4.11p3
glib2-networking-2.44.0 libsoup-2.50.0 librest-0.7.93p0 libdaemon-0.14p1
avahi-0.6.31p19 cups-libs-2.0.4 ghostscript-9.07p2 transfig-3.2.5ap0
gtk-update-icon-cache-3.16.6 djvulibre-3.5.27" to build.

# make print-run-depends

This port requires package(s) "hicolor-icon-theme-0.15 bzip2-1.0.6p1
jbigkit-2.1 xz-5.2.1 dbus-1.8.20v0 dbus-daemon-launch-helper-1.8.20
dbus-1.8.20v0 giflib-5.1.1 jpeg-9a tiff-4.0.4 lcms2-2.6p1 libdaemon-0.14p1
jasper-1.900.1p2 libiconv-1.14p3 libxml-2.9.2p1 gettext-0.19.5.1 gdbm-1.11p0
libltdl-2.4.2p1 ghostscript-fonts-8.11p3 pcre-8.37p1 libtasn1-4.5
fftw3-common-3.2.2p1 fftw3-3.2.2p3 ijs-0.35p2 gmp-5.0.2p3 libnettle-3.1.1
png-1.6.17 netpbm-10.35.96 jbig2dec-0.11 libwebp-0.4.3 libwmf-0.2.8.4p3
libffi-3.1p0 python-2.7.10 p11-kit-0.22.1p1 gnutls-3.3.16 libelf-0.8.13p3
glib2-2.44.1 avahi-0.6.31p19 cups-libs-2.0.4 ghostscript-9.07p2
transfig-3.2.5ap0 shared-mime-info-1.4 gdk-pixbuf-2.30.8p1
gtk-update-icon-cache-3.16.6 djvulibre-3.5.27" to run.

Removing djvu and ghostscript, (almost no loss of functionality):

# make print-build-depends

This port requires package(s) "bzip2-1.0.6p1 jbigkit-2.1 metaauto-1.0p1
xz-5.2.1 png-1.6.17 help2man-1.47.1 autoconf-2.69p1 libffi-3.1p0
autoconf-2.67p0 libltdl-2.4.2p1 giflib-5.1.1 jpeg-9a tiff-4.0.4 lcms2-2.6p1
libwebp-0.4.3 libwmf-0.2.8.4p3 libiconv-1.14p3 gettext-0.19.5.1
gettext-tools-0.19.5.1 gmake-4.1p0 fftw3-common-3.2.2p1 fftw3-3.2.2p3
unzip-6.0p7 jasper-1.900.1p2 groff-1.22.3p2 gdbm-1.11p0 tcl-8.5.18 tk-8.5.18
db-4.6.21p1v0 

npppd pppx0 VPN Client can access wan but cannot access lan

[torsten]

Hi

I'm, running OpenBSD 5.8, npppd, mpath and have tried the same on 5.7 and 5.3.
npppd is works fine and clients can connect using windows pptp client.
The Client has the pptp connection set as default gateway and can access the
internet through the vpn gateway
but cannot access the LAN network.
Traffic arrives on the pppx0 interface but never get forwarded to the LAN ip
address.
I have been looking and trying for over 2 weeks now and can't figure that one
out.
Setting everything to pass in pf.conf and only enabling nat - still no
result.

Setup: OpenBSD 5.8 with npppd using pppx0 or tun0 and pf 2 WAN interfaces
equal cost routing (net.inet.ip.multipath=1), 1 LAN interface

sysctl.conf

net.inet.ip.forwarding=1
net.inet.ip.multipath=1
net.inet.gre.allow=1
net.pipex.enable=1

npptp.conf:

set max-session 20
set user-max-session 5
authentication LOCAL type local {
users-file "/etc/npppd/npppd-users"
}
tunnel VPN protocol pptp {
listen on 0.0.0.0
}
ipcp IPCP {
pool-address 10.219.219.2-10.219.219.100
dns-servers 192.168.0.189 192.168.0.19
nbns-servers 192.168.0.189 192.168.0.19
}
interface pppx0 address 10.219.219.1 ipcp IPCP
bind tunnel from VPN authenticated by LOCAL to pppx0

pf.conf

### NAT
match out log on $ext1_if from $int_net nat-to ($ext1_if)
match out log on $ext2_if from $int_net nat-to ($ext2_if)

  ## vpn
pass quick log on pppx
match out log on $ext1_if from $vpn_net nat-to ($ext1_if)
match out log on $ext2_if from $vpn_net nat-to ($ext2_if)
match out log on $int_if from $vpn_net nat-to ($int_if)

### FILTER RULES
block log quick inet6
block in log on $ext1_if
block in log on $ext2_if

  ## allow ping, traceroute and echo
pass in log inet proto icmp all icmp-type $icmp_types

  ## pass connections to vpn server
pass log proto { gre } from any to any keep state
pass in log on $ext1_if proto tcp from any to $ext1_if port 1723
pass in log on $ext2_if proto tcp from any to $ext2_if port 1723
pass in  on enc0 from $vpn_net to $int_net keep state (if-bound)
pass out on enc0 from $int_net to $vpn_net keep state (if-bound)
pass in  on pppx from $vpn_net to $int_net keep state (if-bound)
pass out on pppx from $int_net to $vpn_net keep state (if-bound)

netstat -rn Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
defaulta.a.a.113  UGSP   0  1073494 - 8 em0
defaultb.b.b.97   UGSP   410294 - 8 em1
10.219.219.1   10.219.219.1   UHl00 - 1 lo0
10.219.219.14  10.219.219.1   UH 0  679 - 8 pppx0
127/8  127.0.0.1  UGRS   00 32768 8 lo0
127.0.0.1  127.0.0.1  UHl14 32768 1 lo0
b.b.b.96/28b.b.b.110  UC 10 - 8 em1
b.b.b.97   bc:16:65:34:33:81  UHLc   10 - 8 em1
b.b.b.110  00:15:17:48:7b:23  HLl00 - 1 lo0
b.b.b.111  b.b.b.110  UHb00 - 1 em1
192.168.0/22   192.168.0.238  UC 90 - 8 em3
192.168.0.400:25:90:7c:40:cf  UHLc   04 - 8 em3
192.168.0.500:30:48:7d:7c:64  UHLc   01 - 8 em3
192.168.0.600:25:90:3c:30:67  UHLc   02 - 8 em3
192.168.0.10   f4:6d:04:29:ea:f7  UHLc   04 - 8 em3
192.168.0.19   00:25:90:72:89:1a  UHLc   0 8388 - 8 em3
192.168.0.189  00:30:48:d8:f0:0b  UHLc   0 9661 - 8 em3
192.168.0.238  00:25:90:d0:17:10  HLl00 - 1 lo0
192.168.0.253  00:25:90:af:5d:0a  UHLc   0  154 - 8 em3
192.168.2.167  50:e5:49:e6:c3:3c  UHLc   0 2048 - 8 em3
192.168.3.202  00:25:90:af:5d:0a  UHLc   1 9329 - L   8 em3
192.168.3.255  192.168.0.238  UHb00 - 1 em3
a.a.a.112/28   a.a.a.126  UC 20 - 8 em0
a.a.a.113  00:00:5e:00:01:0c  UHLc   10 - 8 em0
a.a.a.116  00:25:90:af:5d:0b  UHLc   234417 - L   8 em0
a.a.a.126  00:15:17:48:7b:22  HLl00 - 1 lo0
a.a.a.127  a.a.a.126  UHb00 - 1 em0
224/4  127.0.0.1  URS00 32768 8 lo0

Re: dpb build box performance suggestions.

[Tati Chevron]

On Wed, Dec 16, 2015 at 10:43:43PM +, Christian Weisgerber wrote:

On 2015-12-16, Tati Chevron  wrote:


Our couple of build machines are both fairly standard core i5 boxes with
16 gb of RAM, and Corsair SSDs.  The RAM seems to make more difference
than anything else, because you can set the work directory to a ramdisk,
and do the entire build without touching the disk.


Have you done actual comparisons?  With SSDs, I don't expect a
significant difference.  (There is none for doing a "make build"
of the base system.)


If you're really interested I could probably produce some benchmarks from
one of our build machines, but I did notice a modest increase in performance
doing everything in RAM.

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: openvpn & ./pkitool --initca error

[Tuyosi Takesima]

thanks for Stuart your deep knowlege .

i try easy-rsa on snapsots & ports , but it is not matured .
i wait some time to expect its maturing
reading
  https://openvpn.net/index.php/access-server/docs/quick-start-guide.html .
-
regards

2015-12-15 17:36 GMT+09:00 Stuart Henderson :

> On 2015-12-14, Tuyosi Takesima  wrote:
> > Hi all .
> > about openvpn ,i follow http://www.kernel-panic.it/openbsd/vpn/vpn4.html
> >
> > cp openssl-0.9.6.cnf openssl.cnf
> >
> > and
> > when # ./pkitool
>
> easy-rsa is broken in 5.8 release. If you fetch a -stable ports tree
> from cvs and update easy-rsa you can get a version which has a workaround.
>
> > --initca
> > then
> > Using CA Common Name: changeme
> > error on line 39 of /usr/local/share/easy-rsa/openssl.cnf
> > 6496586334084:error:0E065068:configuration file
> routines:STR_COPY:variable
> > has no
> >
> value:/usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/conf/conf_def.c:573:line
> > 39
> >
> >
> > line 39 of /usr/local/share/easy-rsa/openssl.cnf
> > is
> > 39 dir = $ENV::KEY_DIR # Where everything is kept
>
> This is the config file passed to the openssl(1) tool, /usr/bin/openssl
> (which is LibreSSL in OpenBSD). It's using this syntax to try and pass in
> a variable via the process environment. You might think that the config
> parser for this is in the tool itself, but actually it's in the library(!).
> Changing library behaviour based on environment variables is considered
> dangerous in some cases, so it's been removed from LibreSSL.

Re: mupdf / mutool

[trebol trebol]

> At 16 Dec 2015 22:12:48 + (UTC) from Stefan Wollny :
> Hi there!
> 
> I like mupdf for it's speed with large documents (800+ pages and more). 
> BUT: My usual workflow has it that I need to make printouts of specific 
> pages from those PDFS, sometimes even print the entire document for 
l> egal reasons.
> 
> Anyone around who knows how to achieve this with mupdf/mutool? The man 
> pages for mupdf/mutool do not provide any hints on this and 'startpage' 
> (=google-proxy) didn't come up with anything but "no printing". (I use 
> xpdf again as I do not want to open the doc a second time with xpdf only 
> for printing.)
> 
> TIA.
> 
> Best,
> STEFAN

You can write a script wich execute mupdf and send the the route of the 
directory containing the
pdf to a file in /tmp with the $pid of mupdf in the name. Then you can use your 
wm's key bindings
(or use xbindkeys) to excecute a program (or a shell script, or a Tcl/Tk 
script, or a zenity script with
gtk crap or whatever) to ask for printing options. You can get the pid and the 
file name from the title 
of the focused windows with the help of xdotool, and the directory route from 
the temp file. 
Well, it's an idea, and you can extended to other programs.

Or you can edit the source code and send a patch to the developers.

Good luck.
trebol.

Re: dpb build box performance suggestions.

[Andre Smagin]

On Wed, 16 Dec 2015 23:15:29 +
Tati Chevron  wrote:

> Really, have a look at the dependencies for ImageMagick, and ask yourself
> who really uses djvu, for example.  Removing it and ghostscript reduces
> the dependencies from:

Plenty of people read books in djvu format and use ImageMagick to work
with it. There are many old and valuable, but long out of print books
that were scanned and encoded to djvu format a decade or more ago.
Converting such books to pdf format using open source tools is usually
difficult without drastically reducing the quality or increasing the
file size two- or threefold. And when you do decide to convert, you
need the ImageMagick or similar software.

I am grateful to OpenBSD developers and porters for supporting various
seemingly obscure dependencies and software packages, even though they
may seem to be useless to the majority of the users.

--
Andre

Re: dpb build box performance suggestions.

[Christopher Sean Hilton]

On Wed, Dec 16, 2015 at 11:15:29PM +, Tati Chevron wrote:
> >Or both.  Drop VMWare on the floor NOW, if you need virtualisation use
> >generic QEMU/KVM in any recent Linux distribution of your choice and
> >plan to wipe it clean after you're done fiddling with it.  Yes, really
> >seriously remove the virtualisation for a build machine, go bare metal.
> >Try without hyperthreading for a comparison.  Before you notice and get
> >to complain you need VM for something just use the native OpenBSD
> >hypervisor.
>
> Our build machines both run on bare metal.  To be honest, once you've
> pulled the entire set of source distfiles for one release, you don't even
> need much in the way of connectivity to stay up to date.
> 

Virtual is the only option but I'm not trying to mirror the entire ports
collection. I'm trying run a puppet/package server for a tiny fleet of
soekris boxen.

> From the way the OP described the setup, it does look like he intends to
> run the build machine remotely, as a VPS.  I wouldn't recommend using a
> VPS as a build machine, as you need CPU and RAM with little connectivity,
> which is the opposite of what most VPS providers will offer.  Our build
> machines are on-site, and we just send the resulting binary packages
> wherever they need to go.
>

It's not remote. It runs as one virtual server of two on a 2010
MacPro. My host is modest. It's a 2.8GHz Zeon with 24Gb of RAM and
0.5Tb of SSD. My ports list is equally modest. I generally run OpenBSD
as a server role. If I were to build an OpenBSD desktop, I would rely
on project's mirrors. There's a good argument to be made that me using
dpb is a fools errand but I like to rely on myself. My ports list is
equally modest at 24 ports right now. I expect it to grow but not by much.

> >>Also, be aware that some ports have a mass of unnecessary dependencies,
> >>and that tweaking this can reduce the build time substantially, especially
> >>if you are building the same packages repeatedly for some reason.
> >
> >Use a "virtual" axe ;-) virtually "axing" around.
> 
> Really, have a look at the dependencies for ImageMagick, and ask yourself
> who really uses djvu, for example.  Removing it and ghostscript reduces
> the dependencies from:
> 
> 5.8-release:
> 
> # make print-build-depends

[ massive dependency list snipped... ]

Thank you!!! This hits the nail on the head. One of the twenty four
things I currently want is editors/emacs,gtk2. That wants ImageMagick... I
stopped the dpb build this morning at I=417 ports. As far as I'm
concerned that's off the chain. I'm trying to decide between figuring
out who the big players are in my dependency chain or just going with
editors/emacs,no_x11 and using tramp and or git when I want bells and
whistles emacs.  

-- 
Chris

 __o  "All I was trying to do was get home from work."
   _`\<,_   -Rosa Parks
___(*)/_(*)_
Christopher Sean Hilton[chris/at/vindaloo/dot/com]

Re: Remove "flags S/SA keep state" for tcp packets (SOLVED)

[C.L. Martinez]

On 12/16/2015 08:19 AM, C.L. Martinez wrote:

On 12/15/2015 07:29 PM, Stuart Henderson wrote:

On 2015-12-15, C. L. Martinez  wrote:

On Tue, Dec 15, 2015 at 9:56 AM, David Dahlberg
 wrote:

Am Dienstag, den 15.12.2015, 09:24 + schrieb C. L. Martinez:

  I am trying to remove "flags S/SA keep state" for tcp packets inside
pf.conf and use "keep state" only, as it can do with udp and icmp.

  According to pf.conf man page, this is possible inserting "no state"
in tcp rule, but I can't use keep state.


"keep state" is addressed in pf.conf(5) (e.g. "Stateful Tracking
Options"), but it is not mentioned as often as it is the default.

IOW: If you have not changed the default options, you you may simply
remove "flags S/SA keep state" string without changing mutch (except
that it might now also match UDP/ICMP).



Thanks David. I have not changed any default options but I can't see
how can I remove these flags ... I have tried with "flags any keep
state" without result. If I use "no state", packets are rejected ...


"flags any no state" does remove the "flags s/sa" from the rule.
If that doesn't help then perhaps that's not what the problem is.



Ok, I have done more tests and maybe exists some type of incompatibility
between how OpenBSD manage divert sockets and suricata.

Has anyone tried to use Snort with OpenBSD divert sockets?


Ok, I have done some tests using Snort and it works!! ... Problem seems 
to be with Suricata.


Many thanks to all for your help.

Mono and GTK on OpenBSD

[Lampshade]

Hello,
I would like to learn programming in C# using Mono on OpenBSD.
Is it possible to easily use GtkSharp  GTK# to prepare environment
to create Hello World program using GTK?

Memory exhaustion

[Steve Shockley]

I recently ran into an issue with my OpenBSD mail server where it would 
die every day around 5 AM.  With 5.7-stable it would just become 
unresponsive, with 5.8-stable it would print "scsi_xfer pool exhausted" 
repeatedly on the console.  It turned out to be SpamAsssassin sa-learn 
running on a folder with 26k+ messages, and I simply ran out of memory 
and swap.


I would have preferred to have the sa-learn process just crash instead 
of bringing the system down.  I don't know that I necessarily want to 
put a specific memory limit on the process, I just don't want a process 
to be able to crowd out the kernel.  Is there a sane way to do so?


Dmesg is below.  It's a kvm guest, if that's relevant.  Thanks for reading.

OpenBSD 5.8 (GENERIC.MP) #0: Tue Nov 10 11:57:58 CET 2015

jas...@stable-58-amd64.mtier.org:/binpatchng/work-binpatch58-amd64/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1056952320 (1007MB)
avail mem = 1021083648 (973MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0x3e40 (13 entries)
bios0: vendor Seabios version "0.5.1" date 01/01/2007
bios0: Red Hat KVM
acpi0 at bios0: rev 0
acpi0: sleep states S5
acpi0: tables DSDT FACP SSDT APIC SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: QEMU Virtual CPU version (cpu64-rhel6), 2600.34 MHz
cpu0: 
FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,HV,NXE,LONG,LAHF
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
64b/line 16-way L2 cache

cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: QEMU Virtual CPU version (cpu64-rhel6), 2600.00 MHz
cpu1: 
FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,HV,NXE,LONG,LAHF
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
64b/line 16-way L2 cache

cpu1: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu1: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu1: smt 0, core 0, package 1
cpu2 at mainbus0: apid 2 (application processor)
cpu2: QEMU Virtual CPU version (cpu64-rhel6), 2600.04 MHz
cpu2: 
FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,HV,NXE,LONG,LAHF
cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
64b/line 16-way L2 cache

cpu2: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu2: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu2: smt 0, core 0, package 2
cpu3 at mainbus0: apid 3 (application processor)
cpu3: QEMU Virtual CPU version (cpu64-rhel6), 2600.04 MHz
cpu3: 
FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,HV,NXE,LONG,LAHF
cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 
64b/line 16-way L2 cache

cpu3: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu3: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu3: smt 0, core 0, package 3
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpicpu2 at acpi0: C1(@1 halt!)
acpicpu3 at acpi0: C1(@1 halt!)
pvbus0 at mainbus0: KVM
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, 
channel 0 wired to compatibility, channel 1 wired to compatibility

pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom 
removable

cd0(pciide0:1:0): using PIO mode 0
uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11
piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0 
int 9

iic0 at piixpm0
iic0: addr 0x18 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 
words 00= 01= 02= 03= 04= 05= 06= 07=
iic0: addr 0x1a 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 
words 00= 01= 02= 03= 04= 05= 06= 07=
iic0: addr 0x29 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 
words 00= 01= 02= 03= 04= 05= 06= 07=
iic0: addr 0x2b 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 
words 00= 01= 02= 03= 04= 05= 06= 07=
iic0: addr 0x4c 00=00 01=00 02=00 03=00 

Re: Wireless connection mystery two OpenBSD machines suddenly cannot connect

[lists]

On Tue, 15 Dec 2015 18:05:12 -0700 "Jack J. Woehr"  wrote:

> li...@wrant.com wrote:
> > The next suggestion is to check the modem as well and fix it with a couple 
> > of cents worth of capacitor(s). It is more 
> > likely the modem is source of the problem, especially if it is running a 
> > bit hotter than designed t  
> You're quite sharp. I actually had a brand new one in the closet which I 
> bought a year ago and forgot about, so I 
> removed the old one from service and replaced it.
> 
> Thanks for taking time to reply.
> 

That's right!  Cool tactic, keep a spare at hand.  I have one for the
broadband modem at home too.  Yet I also replace capacitors and debug
hardware problems too so thought it was nice to share mit dem OpenBSD
folk a simple approach to save them cash to contribute.

Hey, no problem, I'm glad I sent a copy to you anyway.  Please
understand the sharpness has nothing to do with your message or topic.

The original post has not yet reached the mailing list as you can see
(happens or other threads too despite passing through spamd is
confirmed).  Too much to read / figure out so why not discard.  This is
getting debugged and sorted one way or another, in the meantime, here
is a re-post (for the list), Mr.moderator believe me it has value and
learning tip as advice:

> Mystery solved. The $3 transformer for the DSL modem is dying. If I
> unplug it and let it cool off everything works again :)  

As you describe it, that may be the modem cooling off, instead or in
addition to the adaptor.  Or an electrolyte capacitor gone dry (in the
modem itself).

> Off to buy a new $3 transformer :)  

The next suggestion is to check the modem as well and fix it with a
couple of cents worth of capacitor(s).  It is more likely the modem is
source of the problem, especially if it is running a bit hotter than
designed to, resulting in reduced life of temperature sensitive
components.

The heat may cause it to operate unstable or lock up, but the original
problem may be unstable power input as you have found out.  But in the
modem itself, and not only the adaptor.  You'll know this is the case if
over the course of its lifetime the device gets to need some time to
start operating after plugging it into power socket.  With ageing it
will completely stop working as power input deteriorates.

If the new adaptor does not eventually solve it for you, you may also
need to swap the modem too eventually.  But before you thrash it, you
may want to anyway open the box and inspect the elements around the
power input circuitry of the modem board.  You may save the device (and
some electronic waste pollution, energy and learn something in the
process), by replacing the most likely failing component(s).

These are dirt cheap and can be found anywhere, if you can't handle
this yourself, a kid you know keen in electronics may have some fun
trying to revive it and actually succeed with a simple replacement of
the power input filtering capacitor(s) in the modem.  Again, still have
a fresh new modem (hint TP-Link? or any other brand) as the fallback
solution, but maybe don't just throw the old one away for recycling,
have a go at it or ask somebody you know may be interested in taking a
look inside.

Same applies to other small electronics devices like table top Ethernet
switches, wireless access points, "routers", VoIP devices, you-name-it,
cordless phone base stations, external broadband modems, TV set-top
boxes, all of these with a life expectancy of less than 3 years by
design.

https://en.wikipedia.org/wiki/Planned_obsolescence

Thus said I have in use modems I bought more than 20 years ago that
still work today without need for any repair but those are a different
type of manufacturing process devices and use cases, of course.  And
still if some device needs repair, it's a capacitor worth less than $1
95% of the time for long term failures.  Please excuse the narrative,
best of luck and don't forget to have fun.

Re: No USB 3.0 on 5.8 -current Broadwell

[Stefan Sperling]

On Wed, Dec 16, 2015 at 03:10:57PM +, Mark Carroll wrote:
> On 20 Nov 2015, edward wandasiewicz wrote:
> 
> > If I try to plug in various USB 3.0 umass(4) devices into a USB 3.0 or
> > USB 3.1 Type C port, nothing gets registered via dmesg, even if I add
> >
> > option USB_DEBUG
> > option UMASS_DEBUG
> > option XHCI_DEBUG
> >
> > and compile a kernel. No dmesg output upon attachment of USB 3.0
> > devices.
> 
> For what it's worth, also on 5.8 stable I also don't see anything twitch
> (dmesg, usbdevs, etc.) if I plug in a USB3 drive.

This was a fix for such a problem in -current very recently.

Re: No USB 3.0 on 5.8 -current Broadwell

[Mark Carroll]

On 20 Nov 2015, edward wandasiewicz wrote:

> If I try to plug in various USB 3.0 umass(4) devices into a USB 3.0 or
> USB 3.1 Type C port, nothing gets registered via dmesg, even if I add
>
> option USB_DEBUG
> option UMASS_DEBUG
> option XHCI_DEBUG
>
> and compile a kernel. No dmesg output upon attachment of USB 3.0
> devices.

For what it's worth, also on 5.8 stable I also don't see anything twitch
(dmesg, usbdevs, etc.) if I plug in a USB3 drive.

> The USB 3.0 devices can only get recognised if I attach them via a USB
> 2.0 cable, and plug this cable into the USB 3.0 or USB 3.1 Type C
> port.

Ha, an interesting discovery! If I put a cheap USB extension cable
(http://www.amazon.co.uk/gp/product/B000BI804Y) inline then suddenly
dmesg /does/ notice the drive,

Dec 16 15:00:47 saffron /bsd: umass0 at uhub0
Dec 16 15:00:47 saffron /bsd:  port 4 configuration 1 interface 0 "Seagate 
Expansion" rev 2.10/7.06 addr 2
Dec 16 15:00:47 saffron /bsd: umass0: using SCSI over Bulk-Only
Dec 16 15:00:47 saffron /bsd: scsibus4 at umass0: 2 targets, initiator 0
Dec 16 15:03:55 saffron /bsd: sd1 at scsibus4 targ 1 lun 0:  SCSI4 0/direct fixed

though not in any useful way, e.g.,

# fdisk sd1
fdisk: sd1: Device not configured

> $ pcidump -v 0:20:0
>
> 0:20:0: Intel 9 Series xHCI
> 0x: Vendor ID: 8086 Product ID: 9cb1

I too have this.

-- Mark

Re: Wireless connection mystery two OpenBSD machines suddenly cannot connect

[lists]

> Mystery solved. The $3 transformer for the DSL modem is dying. If I
> unplug it and let it cool off everything works again :)

As you describe it, that may be the modem cooling off, instead or in
addition to the adaptor.  Or an electrolyte capacitor gone dry (in the
modem itself).

> Off to buy a new $3 transformer :)

The next suggestion is to check the modem as well and fix it with a
couple of cents worth of capacitor(s).  It is more likely the modem is
source of the problem, especially if it is running a bit hotter than
designed to, resulting in reduced life of temperature sensitive
components.

The heat may cause it to operate unstable or lock up, but the original
problem may be unstable power input as you have found out.  But in the
modem itself, and not only the adaptor.  You'll know this is the case if
over the course of its lifetime the device gets to need some time to
start operating after plugging it into power socket.  With ageing it
will completely stop working as power input deteriorates.

If the new adaptor does not eventually solve it for you, you may also
need to swap the modem too eventually.  But before you thrash it, you
may want to anyway open the box and inspect the elements around the
power input circuitry of the modem board.  You may save the device (and
some electronic waste pollution, energy and learn something in the
process), by replacing the most likely failing component(s).

These are dirt cheap and can be found anywhere, if you can't handle
this yourself, a kid you know keen in electronics may have some fun
trying to revive it and actually succeed with a simple replacement of
the power input filtering capacitor(s) in the modem.  Again, still have
a fresh new modem (hint TP-Link? or any other brand) as the fallback
solution, but maybe don't just throw the old one away for recycling,
have a go at it or ask somebody you know may be interested in taking a
look inside.

Same applies to other small electronics devices like table top Ethernet
switches, wireless access points, "routers", VoIP devices, you-name-it,
cordless phone base stations, external broadband modems, TV set-top
boxes, all of these with a life expectancy of less than 3 years by
design.

https://en.wikipedia.org/wiki/Planned_obsolescence

Thus said I have in use modems I bought more than 20 years ago that
still work today without need for any repair but those are a different
type of manufacturing process devices and use cases, of course.  And
still if some device needs repair, it's a capacitor worth less than $1
95% of the time for long term failures.  Please excuse the narrative,
best of luck and don't forget to have fun.

Re: dmesg: notebook hp pavilion dm3 1110eg 13.3"

[Mike Larkin]

On Tue, Dec 15, 2015 at 10:14:23AM +0100, Marcus MERIGHI wrote:
> CCing misc@ because there's no public access to dmesg@.
> 
> BIOS: older machine, nothing fancy
> Xwin: works, incl. touchpad
> Suspend: works without Xwin only
> Resume: does not work, regardless of Xwin

I love these reports that attempt to use the fewest words possible.
It's like taking your car to the mechanic and saying "does not work", and 
letting
them try to figure out what exactly is broken, without providing any
symptoms or other explanation.

-ml

> WLAN: works. fw_update fetched firmware for athn0 via athn0
> 
> dmesg, X.org.log, pcidump, usbdevs, sysctl hw, ifconfig, xdpyinfo,
> xrandr, product specs below.
> 
> OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> RTC BIOS diagnostic error 80
> real mem = 2931224576 (2795MB)
> avail mem = 2838556672 (2707MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe9260 (27 entries)
> bios0: vendor Insyde Corp. version "F.29" date 06/09/2010
> bios0: Hewlett-Packard HP Pavilion dm3 Notebook PC
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP HPET APIC MCFG BOOT SLIC SSDT
> acpi0: wakeup devices SLPB(S3) LID_(S3) PB2_(S4) PB4_(S5) PB5_(S4) PB6_(S5) 
> PB7_(S4) PB9_(S5) PB10(S5) AZAL(S3) USB0(S3) USB1(S3) USB5(S3) P2P_(S5)
> 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 Athlon(tm) Neo X2 Dual Core Processor L335, 1596.22 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,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 256KB 
> 64b/line 16-way L2 cache
> cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 199MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD Athlon(tm) Neo X2 Dual Core Processor L335, 1595.95 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,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,3DNOWP
> cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 256KB 
> 64b/line 16-way L2 cache
> cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
> ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins
> ioapic0: misconfigured as apic 0, remapped to apid 4
> acpimcfg0 at acpi0 addr 0xf700, bus 0-15
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (AGP_)
> acpiprt2 at acpi0: bus 2 (PB2_)
> acpiprt3 at acpi0: bus 3 (PB4_)
> acpiprt4 at acpi0: bus 9 (PB5_)
> acpiprt5 at acpi0: bus -1 (PB6_)
> acpiprt6 at acpi0: bus -1 (PB7_)
> acpiprt7 at acpi0: bus -1 (PB9_)
> acpiprt8 at acpi0: bus -1 (PB10)
> acpiprt9 at acpi0: bus 10 (P2P_)
> acpiec0 at acpi0
> acpicpu0 at acpi0: C1(@1 halt!), PSS
> acpicpu1 at acpi0: C1(@1 halt!), PSS
> acpitz0 at acpi0: critical temperature is 100 degC
> acpibtn0 at acpi0: PWRB
> acpibtn1 at acpi0: SLPB
> acpibtn2 at acpi0: LID_
> acpiac0 at acpi0: AC unit offline
> acpibat0 at acpi0: BAT0 model "5160" serial Li4402A type Li oem " 
> Hewlett-Packard "
> acpivideo0 at acpi0: VGA_
> acpivideo1 at acpi0: VGA_
> cpu0: PowerNow! K8 1596 MHz: speeds: 1600 800 MHz
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "AMD RS780 Host" rev 0x00
> ppb0 at pci0 dev 1 function 0 "AMD RS780 PCIE" rev 0x00
> pci1 at ppb0 bus 1
> radeondrm0 at pci1 dev 5 function 0 "ATI Radeon HD 3200" rev 0x00
> drm0 at radeondrm0
> radeondrm0: apic 4 int 18
> ppb1 at pci0 dev 2 function 0 "AMD RS780 PCIE" rev 0x00: msi
> pci2 at ppb1 bus 2
> radeondrm1 at pci2 dev 0 function 0 "ATI Mobility Radeon HD 4300" rev 0x00
> drm1 at radeondrm1
> radeondrm1: msi
> azalia0 at pci2 dev 0 function 1 "ATI Radeon HD 4000 HD Audio" rev 0x00: msi
> azalia0: no supported codecs
> ppb2 at pci0 dev 4 function 0 "AMD RS780 PCIE" rev 0x00: msi
> pci3 at ppb2 bus 3
> 3:0:0: mem address conflict 0xfffe/0x2
> re0 at pci3 dev 0 function 0 "Realtek 8101E" rev 0x02: RTL8102EL (0x2480), 
> msi, address 00:21:cc:50:1a:a3
> rlphy0 at re0 phy 7: RTL8201L 10/100 PHY, rev. 1
> ppb3 at pci0 dev 5 function 0 "AMD RS780 PCIE" rev 0x00: msi
> pci4 at ppb3 bus 9
> athn0 at pci4 dev 0 function 0 "Atheros AR9285" rev 0x01: apic 4 int 17
> athn0: AR9285 rev 2 (1T1R), ROM rev 14, address c4:46:19:7d:f9:70
> ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x00: apic 4 int 22, 
> AHCI 1.1
> ahci0: port 0: 

Re: Memory exhaustion

[Ted Unangst]

Steve Shockley wrote:
> I would have preferred to have the sa-learn process just crash instead 
> of bringing the system down.  I don't know that I necessarily want to 
> put a specific memory limit on the process, I just don't want a process 
> to be able to crowd out the kernel.  Is there a sane way to do so?

This is tough. We provide resource limits to prevent runaway processes, but
you don't want to use them. I have a problem. Here's the solution. No, no, I
want a different solution...

Limits are preferrable to OOM killing because:

1. It kills the right process, not the process unlucky enough to be targetted
by the "smart" algorithm that decides who's using too much memory.

2. It gives the process the opportunity to deal with the condition gracefully.
It probably won't do much, but at least it's an option.

Re: No USB 3.0 on 5.8 -current Broadwell

[edward wandasiewicz]

Update to 5.8 -current. It now works.

See 1.65 of

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/xhci.c?sortby=date

Edward
On 16 Dec 2015 3:14 p.m., "Mark Carroll"  wrote:

> On 20 Nov 2015, edward wandasiewicz wrote:
>
> > If I try to plug in various USB 3.0 umass(4) devices into a USB 3.0 or
> > USB 3.1 Type C port, nothing gets registered via dmesg, even if I add
> >
> > option USB_DEBUG
> > option UMASS_DEBUG
> > option XHCI_DEBUG
> >
> > and compile a kernel. No dmesg output upon attachment of USB 3.0
> > devices.
>
> For what it's worth, also on 5.8 stable I also don't see anything twitch
> (dmesg, usbdevs, etc.) if I plug in a USB3 drive.
>
> > The USB 3.0 devices can only get recognised if I attach them via a USB
> > 2.0 cable, and plug this cable into the USB 3.0 or USB 3.1 Type C
> > port.
>
> Ha, an interesting discovery! If I put a cheap USB extension cable
> (http://www.amazon.co.uk/gp/product/B000BI804Y) inline then suddenly
> dmesg /does/ notice the drive,
>
> Dec 16 15:00:47 saffron /bsd: umass0 at uhub0
> Dec 16 15:00:47 saffron /bsd:  port 4 configuration 1 interface 0 "Seagate
> Expansion" rev 2.10/7.06 addr 2
> Dec 16 15:00:47 saffron /bsd: umass0: using SCSI over Bulk-Only
> Dec 16 15:00:47 saffron /bsd: scsibus4 at umass0: 2 targets, initiator 0
> Dec 16 15:03:55 saffron /bsd: sd1 at scsibus4 targ 1 lun 0:  Expansion, 0706> SCSI4 0/direct fixed
>
> though not in any useful way, e.g.,
>
> # fdisk sd1
> fdisk: sd1: Device not configured
>
> > $ pcidump -v 0:20:0
> >
> > 0:20:0: Intel 9 Series xHCI
> > 0x: Vendor ID: 8086 Product ID: 9cb1
>
> I too have this.
>
> -- Mark

Re: /bsd: athn0: device timeout

[bluesun08]

In the end i can answer my question myself:

I tested the card in different machines. Now i found one in which the card
works without any problems.

So my result: A working/non working WLAN-Card is a matter of
Mainboard/Hardware/Bios. If these things are reasonable and well proven then
there are no problems.

In doubt try an older but reliable Mainboard/Hardware/Bios. Modern
Mainboard/Hardware/Bios CAN make difficulties.

Thank you all!

Alex 




--
View this message in context: 
http://openbsd-archive.7691.n7.nabble.com/bsd-athn0-device-timeout-tp285288p285519.html
Sent from the openbsd user - misc mailing list archive at Nabble.com.

Re: /bsd: athn0: device timeout

[Kamil Cholewiński]

> In doubt try an older but reliable Mainboard/Hardware/Bios. Modern
> Mainboard/Hardware/Bios CAN make difficulties.

Agree and agree. I've had a vaguely similar experience in 2014 with a
combination of Debian 7, a "latest and greatest" mobo, a noname PCIe
USB3.0 card, a 15m USB extension cable, and five USB webcams. The
webcams would randomly start outputting WAY too dark video streams, once
in 1-3h.

After several weeks of fighting and head-scratching, we've replaced the
"latest and greatest" PC with a mini Dell server. The setup was 100%
reliable following the switch.

One day before the project was delivered, mobo manufacturer releases
errata: PCIe bus would randomly drop voltage. BIOS upgrade would have
fixed it... I was already happy with the Dell though.

K.

Re: Remove "flags S/SA keep state" for tcp packets

[C.L. Martinez]

On 12/15/2015 07:29 PM, Stuart Henderson wrote:

On 2015-12-15, C. L. Martinez  wrote:

On Tue, Dec 15, 2015 at 9:56 AM, David Dahlberg
 wrote:

Am Dienstag, den 15.12.2015, 09:24 + schrieb C. L. Martinez:

  I am trying to remove "flags S/SA keep state" for tcp packets inside
pf.conf and use "keep state" only, as it can do with udp and icmp.

  According to pf.conf man page, this is possible inserting "no state"
in tcp rule, but I can't use keep state.


"keep state" is addressed in pf.conf(5) (e.g. "Stateful Tracking
Options"), but it is not mentioned as often as it is the default.

IOW: If you have not changed the default options, you you may simply
remove "flags S/SA keep state" string without changing mutch (except
that it might now also match UDP/ICMP).



Thanks David. I have not changed any default options but I can't see
how can I remove these flags ... I have tried with "flags any keep
state" without result. If I use "no state", packets are rejected ...


"flags any no state" does remove the "flags s/sa" from the rule.
If that doesn't help then perhaps that's not what the problem is.



Ok, I have done more tests and maybe exists some type of incompatibility 
between how OpenBSD manage divert sockets and suricata.


Has anyone tried to use Snort with OpenBSD divert sockets?

Re: restrictions for kernel interrupt context

[Stefan Sperling]

On Tue, Dec 15, 2015 at 11:04:51PM -0700, Devin Reade wrote:
> The usbd_open_pipe_intr(9) man page discusses the usbd_callback type and
> the usbd_transfer(9) man page mentions the associated interrupt context in
> which (presumably) that callback executes.
> 
> Are there any particular restrictions that apply while running from within
> that interrupt context?

tsleep(9) may not be called.

There may be more, but I've gotten by just fine with the above, so far :)

> In particular, I'm wondering if it's safe to invoke add_true_randomness(9)
> from
> within that interrupt context.

Yes, that should be safe.
 
> In addition to the specific answer, pointers to docs/references are welcome.

The best way to learn about these things is to start writing small but
functional kernel diffs and get them reviewed.  

The "Design and Implementation of *BSD" books might help with getting
the bigger picture. The newer ones are rather FreeBSD-specific but the
older ones (for 4.xBSD) do apply to OpenBSD in lots of ways (but not
in every way). Any such book will only provide very high-level information
and you will have to read the code for details.