Re: Remove "flags S/SA keep state" for tcp packets
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
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.
Re: Remove "flags S/SA keep state" for tcp packets (SOLVED)
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
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
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 04=00 05=00 06=00 07=00 08=00
Re: No USB 3.0 on 5.8 -current Broadwell
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
> 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
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: Wireless connection mystery two OpenBSD machines suddenly cannot connect
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
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: dmesg: notebook hp pavilion dm3 1110eg 13.3"
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: 3.0Gb/s
Re: /bsd: athn0: device timeout
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: Memory exhaustion
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: /bsd: athn0: device timeout
> 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: Memory exhaustion
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.
dpb build box performance suggestions.
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: dpb build box performance suggestions.
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: dmesg: notebook hp pavilion dm3 1110eg 13.3"
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 a
Re: dpb build box performance suggestions.
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.
iwm(4) 11n support: it just works
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 at acpi0: bus -1 (P0PB) acpiprt7 at acpi0: bus -1 (P
mupdf / mutool
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.
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.
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
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 "Intel
Re: dpb build box performance suggestions.
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.
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 pyth
Re: dpb build box performance suggestions.
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
npppd pppx0 VPN Client can access wan but cannot access lan
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.
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
Re: dpb build box performance suggestions.
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: openvpn & ./pkitool --initca error
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: dpb build box performance suggestions.
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: mupdf / mutool
> 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.
