Re: athn panic on 5.5-stable
One more reply to myself, sorry: output of `pcidump`: 7:0:0: Atheros AR9300 0x: Vendor ID: 168c Product ID: 0030 0x0004: Command: 0107 Status: 0010 0x0008: Class: 02 Subclass: 80 Interface: 00 Revision: 01 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 08 0x0010: BAR mem 64bit addr: 0xa300/0x0002 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 106b Product ID: 009a 0x0030: Expansion ROM Base Address: 9800 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 0x0040: Capability 0x01: Power Management 0x0050: Capability 0x05: Message Signaled Interrupts (MSI) 0x0070: Capability 0x10: PCI Express Link Speed: 2.5 / 2.5 GT/s Link Width: x1 / x1
pfsync and trunk
Good morning, I'm having issues with pfsync on trunk interfaces, although I suspect it to be any interface that is slow to start. When I run pfsync on a vlan interface on a trunk(4), the pfsync bulk transfer never completes. Running pfsync on an interface that starts quickly I see: 07:41:45.982402 arp who-has 10.240.252.2 tell 10.240.252.2 07:41:45.982517 10.240.252.2: PFSYNCv6 len 36 act UPD ST REQ count 1 id: creatorid: (DF) [tos 0x10] 07:41:45.982606 10.240.252.1: PFSYNCv6 len 36 act BULK UPD STAT count 1 creatorid: e9bd40d6 age: 00:00:00 status: start (DF) [tos 0x10] ...snip... 07:41:46.062065 10.240.252.1: PFSYNCv6 len 304 act BULK UPD STAT count 1 creatorid: e9bd40d6 age: 00:00:01 status: end act UPD ST count 1 ... (DF) [tos 0x10] Running on pfsync on trunk(4) that initial request never shows up, and the bulk update never starts/finishes. I would like to run pfsync on trunk(4) lacp link, but as it looks now I have firewalls with carp demote counter 33 forever. Anyone else having problems with this ? Anything I can do to improve the situation ? Tested with 5.4 and 5.5, real and virtual machines, failover and lacp trunk(4). Regards Tony
Re: athn panic on 5.5-stable
and of course I forgot my dmesg, so here it is:
OpenBSD 5.5-stable (GENERIC) #1: Fri Aug 22 01:27:55 EST 2014
r...@bia.my.domain:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Genuine Intel(R) CPU @ 1.00GHz ("GenuineIntel" 686-class) 1.01 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF
real mem = 1073098752 (1023MB)
avail mem = 1043267584 (994MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 20/21/15, BIOS32 rev. 0 @ 0xfac40
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu at mainbus0: not configured
mpbios0: bus 0 is type PCI
mpbios0: bus 64 is type ISA
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf3880/96 (4 entries)
pcibios0: no compatible PCI ICU found: ICU vendor 0x8086 product 0x8186
pcibios0: Warning, unable to fix up PCI interrupt routing
pcibios0: PCI bus #13 is the last bus
bios0: ROM list: 0xc8000/0x2400 0xca800/0x4c00 0xcf800/0xee00
cpu0: unknown Enhanced SpeedStep CPU, msr 0x06090a0a06000a0d
cpu0: using only highest, current and lowest power states
cpu0: Enhanced SpeedStep 1001 MHz: speeds: 1000, 1000, 600 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel E600 Host" rev 0x05
pchb1 at pci0 dev 1 function 0 "Intel E600 Config" rev 0x00
ppb0 at pci0 dev 23 function 0 "Intel E600 PCIE" rev 0x00
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "Intel EG20T PCIE" rev 0x01
pci2 at ppb1 bus 2
"Intel EG20T Packet Hub" rev 0x01 at pci2 dev 0 function 0 not configured
"Intel EG20T Ethernet" rev 0x02 at pci2 dev 0 function 1 not configured
"Intel EG20T GPIO" rev 0x01 at pci2 dev 0 function 2 not configured
ohci0 at pci2 dev 2 function 0 "Intel EG20T USB" rev 0x02: apic 0 int
19, version 1.0
ohci1 at pci2 dev 2 function 1 "Intel EG20T USB" rev 0x02: apic 0 int
19, version 1.0
ohci2 at pci2 dev 2 function 2 "Intel EG20T USB" rev 0x02: apic 0 int
19, version 1.0
ehci0 at pci2 dev 2 function 3 "Intel EG20T USB" rev 0x02: apic 0 int 19
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
"Intel EG20T USB Client" rev 0x02 at pci2 dev 2 function 4 not configured
sdhc0 at pci2 dev 4 function 0 "Intel EG20T SDIO" rev 0x01: apic 0 int 18
sdmmc0 at sdhc0
sdhc1 at pci2 dev 4 function 1 "Intel EG20T SDIO" rev 0x01: apic 0 int 18
sdmmc1 at sdhc1
ahci0 at pci2 dev 6 function 0 "Intel EG20T AHCI" rev 0x02: msi, AHCI 1.1
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0: SCSI3
0/direct fixed naa.5001b44828274e8b
sd0: 22902MB, 512 bytes/sector, 46905264 sectors, thin
ohci3 at pci2 dev 8 function 0 "Intel EG20T USB" rev 0x02: apic 0 int
16, version 1.0
ohci4 at pci2 dev 8 function 1 "Intel EG20T USB" rev 0x02: apic 0 int
16, version 1.0
ohci5 at pci2 dev 8 function 2 "Intel EG20T USB" rev 0x02: apic 0 int
16, version 1.0
ehci1 at pci2 dev 8 function 3 "Intel EG20T USB" rev 0x02: apic 0 int 16
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1
"Intel EG20T DMA" rev 0x00 at pci2 dev 10 function 0 not configured
puc0 at pci2 dev 10 function 1 "Intel EG20T Serial" rev 0x01: ports: 1 com
com4 at puc0 port 0 apic 0 int 19: ti16750, 64 byte fifo
puc1 at pci2 dev 10 function 2 "Intel EG20T Serial" rev 0x00: ports: 1 com
com5 at puc1 port 0 apic 0 int 19: ti16750, 64 byte fifo
puc2 at pci2 dev 10 function 3 "Intel EG20T Serial" rev 0x00: ports: 1 com
com6 at puc2 port 0 apic 0 int 19: ti16750, 64 byte fifo
puc3 at pci2 dev 10 function 4 "Intel EG20T Serial" rev 0x00: ports: 1 com
com7 at puc3 port 0 apic 0 int 19: ti16750, 64 byte fifo
"Intel EG20T DMA" rev 0x00 at pci2 dev 12 function 0 not configured
"Intel EG20T SPI" rev 0x00 at pci2 dev 12 function 1 not configured
"Intel EG20T I2C" rev 0x00 at pci2 dev 12 function 2 not configured
"Intel EG20T CAN" rev 0x00 at pci2 dev 12 function 3 not configured
"Intel EG20T 1588" rev 0x01 at pci2 dev 12 function 4 not configured
usb2 at ohci0: USB revision 1.0
uhub2 at usb2 "Intel OHCI root hub" rev 1.00/1.00 addr 1
usb3 at ohci1: USB revision 1.0
uhub3 at usb3 "Intel OHCI root hub" rev 1.00/1.00 addr 1
usb4 at ohci2: USB revision 1.0
uhub4 at usb4 "Intel OHCI root hub" rev 1.00/1.00 addr 1
usb5 at ohci3: USB revision 1.0
uhub5 at usb5 "Intel OHCI root hub" rev 1.00/1.00 addr 1
usb6 at ohci4: USB revision 1.0
uhub6 at usb6 "Intel OHCI root hub" rev 1.00/1.00 addr 1
usb7 at ohci5: USB revision 1.0
uhub7 at usb7 "Intel OHCI root hub" rev 1.00/1.00 addr 1
ppb2 at pci0 dev 24 function 0 "Intel E600 PCIE" rev 0x00
pci3 at ppb2 bus 3
ppb3 at pci3 dev 0 function 0 "IDT 89HPES4T4" rev 0x0e
pci4 at ppb3 bus 4
ppb4 at pci4 dev 2 function 0 "IDT 89HPES4T4" rev 0x0e
p
athn panic on 5.5-stable
Hello, I have a Soekris net6501-50 with an Atheros AR9380 (model AR5BXB112) wireless card attached to a Mini PCI Express slot. When attempting to `ifconfig athn0 scan`, or otherwise interact with the interface, I trigger a panic. I’ve tried both with and without the athn firmware installed via `fw_update`, and even tested the card in a PCI-E adapter. Here’s the panic line: panic: kernel diagnostic assertion "pin < sc->ngpiopins" failed: file "../../../../dev/ic/ar9003.c", line 514 I've included trace, ps, registers and objdump output below. Any help would be appreciated! Cheers, Mark `trace` output: ddb> trace Debugger(d09da499,f54bc948,d09b7298,f54bc948,0) at Debugger+0x4 panic(d09b7298,d0935a26,d0996d20,d099eec4,202) at panic+0x67 __assert(d0935a26,d099eec4,202,d0996d20,1) at __assert+0x2e ar9003_gpio_write(d1f4,ff,1,d1f4,d1f4) at ar9003_gpio_write+0xa2 athn_set_led(d1f4,0,0,1,80) at athn_set_led+0x31 athn_led_init(d1f4,7f,0,f54bc9ec,d0203009) at athn_led_init+0x35 athn_init(d1f40030,d0b21068,d6efb220,d2491200,d1f40030) at athn_init+0xe8 athn_ioctl(d1f40030,8020690c,d2491200,d0427410,d2491228) at athn_ioctl+0x1cc in6_ifinit(d1f40030,d2491200,1,d03c6d49,d6cce2ac) at in6_ifinit+0xbe in6_update_ifa(d1f40030,f54bcc10,0,0,0) at in6_update_ifa+0x292 in6_ifattach_linklocal(d1f40030,0,f54bcd7c,3c50,f8214ba2) at in6_ifattach_linkl ocal+0x128 in6_ifattach(d1f40030,0,f54bcd7c,d03c78a5,f54bcd68) at in6_ifattach+0xdd in6_if_up(d1f40030,d09bd23c,cfbd5000,3c02d003,80206910) at in6_if_up+0x13 if_up(d1f40030,0,0,3c02d003,d1cf9030) at if_up+0x6e ifioctl(d6c8ec40,80206910,f54bce84,d6cded68,f54bcec8) at ifioctl+0xcdb sys_ioctl(d6cded68,f54bcf64,f54bcf84,f54bcfa8,d6e59b00) at sys_ioctl+0x144 syscall() at syscall+0x214 --- syscall (number 10) --- 0x2: `ps` output: ddb> ps PID PPID PGRPUID S FLAGS WAIT COMMAND *20727 19085 20727 0 7 0x3ifconfig 19085 7999 19085 0 30x8b pause zsh 7999 12432 7999 1000 30x8b pause zsh 12432 1 12432 1000 2 0tmux 8775 3974 8775 1000 30x83 kqreadtmux 3974 28811 3974 1000 30x8b pause zsh 28811 3693 3693 1000 30x90 selectsshd 3693 9282 3693 0 30x92 poll sshd 19024 1 19024 0 30x83 ttyin getty 9267 1 9267 0 30x80 selectcron 31441 1 31441 0 30x80 nanosleep watchdogd 2267 1 2267601 30x90 kqreadunbound 30127 1 30127688 30x90 kqreaddnscrypt-proxy 10904 1 10904 0 30xb0 selectsendmail 4418 1 4418 77 30x90 poll dhcpd 9282 1 9282 0 30x80 selectsshd 31370 21117 10004 83 30x90 poll ntpd 21117 10004 10004 83 30x90 poll ntpd 10004 1 10004 0 30x80 poll ntpd 14077 21793 21793 74 30x90 bpf pflogd 21793 1 21793 0 30x80 netio pflogd 7320 31362 31362 73 30x90 poll syslogd 31362 1 31362 0 30x80 netio syslogd 21221 0 0 0 3 0x4200 aiodoned aiodoned 23527 0 0 0 3 0x4200 syncerupdate 13509 0 0 0 3 0x4200 cleaner cleaner 25814 0 0 0 3 0x4200 reaperreaper 30850 0 0 0 3 0x4200 pgdaemon pagedaemon 30879 0 0 0 3 0x4200 bored crypto 11107 0 0 0 3 0x4200 pftm pfpurge 8157 0 0 0 3 0x4200 mmctsksdmmc1 26366 0 0 0 3 0x4200 mmctsksdmmc0 24641 0 0 0 3 0x4200 usbtskusbtask 28718 0 0 0 3 0x4200 usbatsk usbatsk 16005 0 0 0 3 0x4200 bored sensors 21790 0 0 0 3 0x4200 bored systq 19530 0 0 0 3 0x4200 bored syswq 30656 0 0 0 3 0x40004200idle0 25734 0 0 0 3 0x4200 kmalloc kmthread 1 0 1 0 30x82 wait init 0 -1 0 0 3 0x200 scheduler swapper `show registers` output: ddb> show registers ds 0x10 es 0x10 fs 0x20 gs 0 edi 0xd09b7298systq+0x1ae0 esi0x100 ebp 0xf54bc8fc ebx 0xf54bc948 edx 0x1 ecx 0xd0b2008ckprintf_mutex eax 0x1 eip 0xd055fc74Debugger+0x4 cs 0x8 eflags
Re: Help, please, understanding AHCI error on amd64
On 08/29/14 16:04, Evan Root wrote:
> It seems that after reading the backblaze and google papers about drive
> reliability that there is no statistically obvious difference. It's too
> close to call. Both papers end with hedges and further questions. Even if
> enterprise drives are more reliable it isn't by more than a single percent
> and it isn't consistent enough to matter either.
>
> Evan Root, CCNA
there's more to it than just the drives, though.
You have to count the interface, drivers and everything else in the disk
subsystem. When you do this, I think there is a very clear winner: IDE
and SATA disks on dull, boring interfaces. (for what it is worth, I'm
not sure AHCI is "dull and boring" yet. Hopefully soon, though, looking
forward to being able to call it that, as AHCI rocks).
Just about everyone gets IDE and SATA right in software. I've seen
problems with SCSI, SAS, and RAID drivers in almost every OS.
When it comes to reliabilty, simplicity rocks. Simple systems have
simple problems. Complex systems have all the problems of simple
systems, plus complex problems of their own. SCSI and SAS hot-swap
backplanes are a good example: ever see one fail on your server? If you
tend more than a dozen, I bet you have. Ever see them fail on a desktop
with a SATA or IDE drive? Of course not. Can't fail if it isn't there!
(actually, SCSI/SAS back plane failures are kind of amazing if you
think about it -- hardly an active part on them!). More, if your SATA
cable is bad, you can get a new one in minutes by stripping a less
critical machine, an hour if you have to go buy one, vs. having to find
the precise part for YOUR server.
To skew the results even more, consider the manufacturers who lock their
systems so only THEIR drives can be used with their machines. They will
give you a line of bullshit about "oh, we've tested them and they are
more reliable!". I have come to the conclusion that these people are
either idiots or liars, and I don't give a rat's ass which, either way,
their products don't belong in my data center. How many people have
seen those manufacturers change hw providers, and suddenly need firmware
or driver upgrades to support those new devices...with catastrophic
failures when you don't install those BEFORE the new disk?
When's the last time you saw a firmware or driver update for a SATA or
IDE device, vs. what's the FIRST thing IBM, Dell or HP will tell you
when your expensive server crashes? ("Update everything, call me if it
happens again").
What's the last time your old server went wonky because the cache
battery was declared bad...and yet, you couldn't just go down to
Batteries-R-Us and pick up a new $5 battery, you had to buy YOUR BRAND's
replacement battery with a three-digit price tag (and a stupid ID chip
to tell the cache controller that the idiot/liars blessed this battery).
Yes, they'll give you reasons for all those design decisions, but
reality is, they cause you failures and down time that is 100% preventable.
I've done statistically interesting, if not significant, comparisons
between simple workstations with simple hw mirroring SATA systems vs.
high-end servers at 4+ times the price, for the same application running
the same software in the same company, and from a reliability
standpoint, it was a clear victory -- for the cheap workstations with
consumer-grade disks (it wasn't just the disks, either).
Nick.
Re: rc.local mystery executables
grc.*** (because I don't want any more googgle weight given to this website) and the person who runs it, whose name shall not be mentioned other than his initials are SG, is a complete fraud. On Fri, Aug 29, 2014, at 08:37 PM, Scott Bonds wrote: > On Tue, Aug 19, 2014 at 03:24:08AM -0400, Todd Zimmermann wrote: > > > Just off the top my head a few links: > > www.team-cymru.org > > https://www.dshield.org > > http://emergingthreats.net/ > > https://www.grc.***/dns/dns.htm > > > I stumbled upon malheur awhile back. No idea what to do with it, but > > it compiles easy on obsd. Since you found the malware files it might > > help. > > > > http://www.mlsec.org/malheur/ > > Thanks, I'll check these out.
Re: rc.local mystery executables
On Tue, Aug 19, 2014 at 03:24:08AM -0400, Todd Zimmermann wrote: > Just off the top my head a few links: > www.team-cymru.org > https://www.dshield.org > http://emergingthreats.net/ > https://www.grc.com/dns/dns.htm > I stumbled upon malheur awhile back. No idea what to do with it, but > it compiles easy on obsd. Since you found the malware files it might > help. > > http://www.mlsec.org/malheur/ Thanks, I'll check these out.
nginx gzip crippled?
Hey all, Can someone tell me why nginx's "gzip on" option doesn't work in 5.5 release? Thanks.
Re: Help, please, understanding AHCI error on amd64
Evan Root [cellarr...@gmail.com] wrote: > It seems that after reading the backblaze and google papers about drive > reliability that there is no statistically obvious difference. It's too > close to call. Both papers end with hedges and further questions. Even if > enterprise drives are more reliable it isn't by more than a single percent > and it isn't consistent enough to matter either. > The difference in firmware between consumer and enterprise drives can be papered over with a good RAID controller. The kernel might need to timeout or do something. But the problem should be attacked there instead of saying "oh just buy the 5x cost drive".
Re: Help, please, understanding AHCI error on amd64
On 08/29/2014 04:04 PM, Evan Root wrote: > It seems that after reading the backblaze and google papers about drive > reliability that there is no statistically obvious difference. It's too > close to call. Both papers end with hedges and further questions. Even if > enterprise drives are more reliable it isn't by more than a single percent > and it isn't consistent enough to matter either. > > Evan Root, CCNA > > > > On Thu, Aug 28, 2014 at 1:40 PM, Chris Cappuccio wrote: > >> Christian Weisgerber [na...@mips.inka.de] wrote: >>> Now, the real question is whether enterprise drives actually *are* >>> more reliable than consumer drives. >>> >> For regular hard disks, the answer is definitely, no. What I extract from the various verbiage is: Under benign conditions, i.e. no significant vibration and good cooling, the two are virtually equally reliable. Under harsh conditions, specifically high vibration and high heat due to constant activity, the desktop drives are likely to fail quickly and the enterprise drives will continue to operate. The various grades of WD disks are labeled as to how many disks will be in the chassis. IIRC something like 1 or 2, up to 5, and lots for the 3 grades. This corresponds to the amount of vibration hardening. Now, with good cooling and some shock mounting which does vibration isolation but holds the drives so that they don't move during seeks (conflicting requirements, ingenuity required) desktop drives might be usably reliable. So comparing reliability statistics is only meaningful if the case, cabinet, and cooling are equivalent. My guess is that the enterprise drives are aimed at data centers which pack drives into the smallest possible space and can't afford to pull them to replace them. They would pay the 3X premium.
Re: minimums for /usr/ports, /usr/xenocara, and /usr/src
Hi Joel, Joel Rees wrote on Thu, Aug 28, 2014 at 03:26:58PM +0900: > Oh, BTW, the output of the command Ingo suggested, > >find /usr/ports -name pobj -prune -o -type d -empty -print > > is empty. Well, your checkout should be fine, then. Pruning directories only starts after the update is complete, and if there are no empty directories left, then pruning of empty directories obviously completed successfully, too. > (Thanks, Ingo, now I need to dig around and see if I can find > where I read about files named pobj again.) Oh, in that respect, i admit to notational sloppiness. I should have written "-path /usr/ports/pobj" instead of "-name pobj". That's the directory where ports are built. It is not part of the CVS checkout. In there, empty directories may well exist, but that doesn't tell you anything about the integrity of your checkout. Look for WRKOBJDIR in bsd.port.mk(5). Yours, Ingo
Re: Help, please, understanding AHCI error on amd64
It seems that after reading the backblaze and google papers about drive reliability that there is no statistically obvious difference. It's too close to call. Both papers end with hedges and further questions. Even if enterprise drives are more reliable it isn't by more than a single percent and it isn't consistent enough to matter either. Evan Root, CCNA On Thu, Aug 28, 2014 at 1:40 PM, Chris Cappuccio wrote: > Christian Weisgerber [na...@mips.inka.de] wrote: > > > > Now, the real question is whether enterprise drives actually *are* > > more reliable than consumer drives. > > > > For regular hard disks, the answer is definitely, no.
Re: Managed DNS recommendation
That means they screwed up somewhere. Yes, you'll have to create a new account on their new system - that's kind of the point, they acquired the business and transitioned it to their own platform. I've been dealing with (and recommending) EasyDNS since 1999, and their technical support is easily the best in the industry - call their support # and talk to a human. -Adam On August 29, 2014 12:49:10 PM CDT, Predrag Punosevac wrote: >This is not strictly OpenBSD based question but I highly value advises >from this list. > >I just logged into our ZoneEdit account which is recently acquired by >EasyDNS of Toronto. To my horror I found out that our renewal date has >conveniently changed from August of 2018 to two weeks from now. I >called >EasyDNS customer service who conceded that transition is very tricky >and >they can't help me with my ZoneEdit account but would be happy to open >their own account. ZoneEdit can be reached only via e-mail. > >Long story short I am going to pull the trigger and changed our managed >DNS provider. I just learnt that EasyDNS is BIND based. Any >recommendation in particular for NSD based providers. > >Cheers, >Predrag -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Managed DNS recommendation
On 8/29/14, Predrag Punosevac wrote: > This is not strictly OpenBSD based question but I highly value advises > from this list. > > I just logged into our ZoneEdit account which is recently acquired by > EasyDNS of Toronto. To my horror I found out that our renewal date has > conveniently changed from August of 2018 to two weeks from now. I called > EasyDNS customer service who conceded that transition is very tricky and > they can't help me with my ZoneEdit account but would be happy to open > their own account. ZoneEdit can be reached only via e-mail. > > Long story short I am going to pull the trigger and changed our managed > DNS provider. I just learnt that EasyDNS is BIND based. Any > recommendation in particular for NSD based providers. For what it's worth, I've been using EasyDNS since mid 90s. My experience with their support staff has been _fantastic_! I don't use them specifically for DNS, however. Disclaimer, I am acquainted with EasyDNS founder, Mark J., who is super nice guy. That said, I've had more 1-on-1 correspondences with a handful of OBSD developers in the past, say, year, than I have in a decade with Mark. --patrick
Managed DNS recommendation
This is not strictly OpenBSD based question but I highly value advises from this list. I just logged into our ZoneEdit account which is recently acquired by EasyDNS of Toronto. To my horror I found out that our renewal date has conveniently changed from August of 2018 to two weeks from now. I called EasyDNS customer service who conceded that transition is very tricky and they can't help me with my ZoneEdit account but would be happy to open their own account. ZoneEdit can be reached only via e-mail. Long story short I am going to pull the trigger and changed our managed DNS provider. I just learnt that EasyDNS is BIND based. Any recommendation in particular for NSD based providers. Cheers, Predrag
Re: httpd URI rewriting / try_files
On 08/28/14 15:15, Christopher Zimmermann wrote:
On Thu, 28 Aug 2014 14:37:34 +0300 Gregory Edigarov
wrote:
Hello
are there any plans to implement uri rewriting or something in a manner
of 'try_files' configuration option of nginx?
I plan to add a URL stripping option, somewhat more powerful than the
nginx alias directive:
root [strip number] directory
Set the document root of the server. The directory is a
pathname within the chroot(2) root directory of httpd. If not
specified, it defaults to /htdocs. If the strip option is set, number
path components are removed from the beginning of the URI before
directory is prepended.
this would allow you to do for example:
location "/wiki/" {
strip 1
root "/dokuwiki"
directory index "doku.php"
fastcgi socket "/tmp/php.sock"
}
it would be absolutely nice to have something like try_files for
locations and servers.
like
location "/some/" {
root "/some/"
try_files $uri index.php?$uri
}
Re: minimums for /usr/ports, /usr/xenocara, and /usr/src
On 08/28/14 02:26, Joel Rees wrote: > Finally getting a chance to look at this again, and I had a couple of > questions. > > One, am I right that cvs co and cvs get are basically the same thing? > > (get, per http://www.openbsd.org/anoncvs.html , > and co, per http://www.openbsd.org/faq/faq5.html#Bld .) from "man cvs" : checkout [options] modules... Requires: repository. Changes: working directory. Synonyms: co, get Make a working directory containing copies of the source files specified by modules. You must execute `cvs checkout' before using most of the other cvs commands, since most of them operate on your working directory. so...yes. > The other, assuming that the last package showing update (U) before the > broken pipe is now something like x11/xfce4, would it make sense to, with > the current working directory still at /usr, issue > >sudo cvs -d$CVSROOT co -P ports/x11 > > or > >cvs -qd anon...@anoncvs.jp.openbsd.org:/cvs get -P ports/x11 > > just to be really, really, paranoid sure? no, I'd just do a "cvs -Pd up" within the ports directory. Updating your tree will restore any missing files. Nick.
Re: httpd URI rewriting / try_files
On 2014-08-28 Thu 22:14 PM |, Liviu Daia wrote: > > What about redirect, say from http://mumble to https://mumble? > Or: http://example.org -> http://www.example.org http://www.example.com -> http://www.example.net
Thinkpad T410: GPU becomes wedged when resizing windows
Hi! I'm running the Aug 23 snapshot on a Thinkpad T410, usually connected to an external display. Sometimes, when I resize a window while the display is set to a high resolution (e.g., 1920x1200 or 1600x1200), the screen "freezes" for a moment and the following messages appear on the console. Aug 28 23:56:12 trav /bsd: error: [drm:pid12469:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung Aug 28 23:56:13 trav /bsd: error: [drm:pid12469:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung Aug 28 23:56:13 trav /bsd: error: [drm:pid556:i915_reset] *ERROR* GPU hanging too fast, declaring wedged! Aug 28 23:56:13 trav /bsd: error: [drm:pid556:i915_reset] *ERROR* Failed to reset chip. After that happens, XVideo output won't work anymore until I reboot. I can trigger this by wildly resizing, e.g., a firefox window for a couple of seconds, but it also sometimes happens during normal use. With a resolution of 1280x1024, I can resize all I want without problems. I've been noticing this problem since I got a larger monitor, so I don't know for which snapshots/releases this problem exists. Maybe the GPU is just too slow? However, in general, everything runs pretty smooth. Thanks to everyone taking the time to have a look at this! If you need some more information, please ask. dmesg: OpenBSD 5.6-current (GENERIC.MP) #342: Sat Aug 23 06:39:47 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4062691328 (3874MB) avail mem = 3945811968 (3763MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries) bios0: vendor LENOVO version "6IET79WW (1.39 )" date 07/15/2011 bios0: LENOVO 252225G acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2793.47 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 133MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2793.01 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2793.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 5 (application processor) cpu3: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2793.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 2, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpiprt5 at acpi0: bus 5 (EXP4) acpiprt6 at acpi0: bus 13 (EXP5) acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpicpu2 at acpi0: C3, C1, PSS acpicpu3 at acpi0: C3, C1, PSS acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2 acpitz0 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 not present acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 cpu0: Enhanced SpeedStep 2793 MHz: speeds: 2534, 2533, 2399, 2266, 2133, 1999, 1866, 1733, 1599, 1466, 1333, 1199 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core Host" rev 0x02 vga1 at pci0 dev 2 functio
