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
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
Automated PXE install with Serva (updated)
Hi, I'm installing install55.iso with Serva. Serva is an automated PXE server that let us install many OSs (including OpenBSD) from a menu. It is interesting to know that even when there are some rough edges OpenBSD is today the only BSD distro capable of being installed by an automated PXE server. I'd like to share with you guys those rough edges and see if they can probably be addressed in future releases. The idea behind Serva is that the distro's ISO directly becomes part of Serva's repository when its content is directly copied under a certain directory controlled by the PXE server. Problems: 1) The PXE install process asks for the file .\5.5\amd64\index.txt but the distro names it .\5.5\amd64\TRANS.TBL; probably just renaming this file or adding .\5.5\amd64\index.txt to the distro will solve the issue. 2) The PXE install process looks after .\5.5\amd64\SHA256.sig but the distro includes .\5.5\amd64\SHA256 ; I think the distro should include SHA256.sig or both. 3) The PXE install process needs .\5.5\amd64\etc\boot.conf but the distro has not .\etc\boot.conf ; probably it would be a good idea adding a default .\5.5\amd64\etc\boot.conf in the distro's ISO containing i.e. a single line like boot bsd.rd 4) OpenBSD automated installs look after /install.conf; this is an absolute path and that is a deal breaker when it comes to multi OS PXE servers like Serva; then why not alternative look for that file in ./5.5/amd64/etc/install.conf in the same way the install now looks for ./5.5/amd64/etc/boot.conf ? 5) Automated PXE servers usually use configuration files that deal with the distro ISO directory structure. It is never a good idea adopting a differentiated structure based in i.e. architecture. That forces automated tools to deal with a different script for every architecture. .\5.5\amd64\ .\5.5\i386\ etc. It is always a better idea to have a constant directory structure like .\5.5\bin\ with an empty file at root with its name indicating the corresponding architecture 6) OpenBSD automated installs require the repository url or IP; on a PXE environment that IP is very often the parameter next-server gathered from the initial PXE DHCP transaction. It would be very handy having a wildcard like %next-server% that can be interpreted when parsing install.conf. This way we do not have to manually add a different repository IP for every different PXE scenario I think if some of these issues can be addressed OpenBSD PXE install capabilities will be greatly improved not just only for Serva but for every PXE server out there. You guys can see here the ServaAsset.inf required to PXE boot OpenBSD and other non-windows assets. http://vercot.com/~serva/an/NonWindowsPXE3.html Thanks
Re: athn panic on 5.5-stable
On Sat, Aug 30, 2014 at 03:20:54PM +1000, mark hellewell wrote: 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! Beware, the ar9003 parts of athn are somewhat broken and unfinished. That said, can you try this? Index: ar9003.c === RCS file: /cvs/src/sys/dev/ic/ar9003.c,v retrieving revision 1.30 diff -u -p -r1.30 ar9003.c --- ar9003.c22 Jul 2014 13:12:11 - 1.30 +++ ar9003.c30 Aug 2014 08:22:26 - @@ -165,6 +165,8 @@ ar9003_attach(struct athn_softc *sc) struct athn_ops *ops = sc-ops; int error; + sc-ngpiopins = 16; + /* Set callbacks for AR9003 family. */ ops-gpio_read = ar9003_gpio_read; ops-gpio_write = ar9003_gpio_write;
Re: rc.local mystery executables
2014/08/30 12:20 Eric Furman ericfur...@fastmail.net: 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. The first two paragraphs didn't seem too bad. But DoG ? Brute force doesn't have to be blind. I think I agree with you. 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: kernel page fault on 55-release
Hello Ludovic, On 28/08/14(Thu) 20:52, ludovic coues wrote: Hello, Recently, I get a kernel page fault every time I try to use the micronucleus [1] command line tool. It 's for uploading an hex file to ATtiny processor, much like arduino's avrude. The crash is pretty consistent, occuring every time I run `micronucleus --run`. I've managed to use it with success in the past on this machine with 55-release so it might be hardware related. I added a realtek wireless device since last time I've get a successful run with micronucleus. I get the following message when I run it: uvm_fault(0x81daaf001, 0x2, 2, 0, 1) - e kernel: page fault trap, code=0 Stopped at usbd_get_cdesc+035: movzwl 0x2 (%rax),%eax It's followed by the debugger prompt. I don't know how what to do from that point. I'm willing to spend time tracking the source of the problem but I have no idea of what I'm looking for. Thanks for reporting the problem. I believe this is the same issue that has been reported by Thomas Pfaff in February [0] and fixed post 5.5 [1]. Could you try a snapshot and tell me if you can still reproduce it? Cheers, Martin [0] http://marc.info/?l=openbsd-bugsm=139135208628637w=2 [1] http://marc.info/?l=openbsd-cvsm=139194643911061w=2
Re: kernel page fault on 55-release
2014-08-30 10:53 GMT+02:00 Martin Pieuchot mpieuc...@nolizard.org: Hello Ludovic, On 28/08/14(Thu) 20:52, ludovic coues wrote: Hello, Recently, I get a kernel page fault every time I try to use the micronucleus [1] command line tool. It 's for uploading an hex file to ATtiny processor, much like arduino's avrude. The crash is pretty consistent, occuring every time I run `micronucleus --run`. I've managed to use it with success in the past on this machine with 55-release so it might be hardware related. I added a realtek wireless device since last time I've get a successful run with micronucleus. I get the following message when I run it: uvm_fault(0x81daaf001, 0x2, 2, 0, 1) - e kernel: page fault trap, code=0 Stopped at usbd_get_cdesc+035: movzwl 0x2 (%rax),%eax It's followed by the debugger prompt. I don't know how what to do from that point. I'm willing to spend time tracking the source of the problem but I have no idea of what I'm looking for. Thanks for reporting the problem. I believe this is the same issue that has been reported by Thomas Pfaff in February [0] and fixed post 5.5 [1]. Could you try a snapshot and tell me if you can still reproduce it? Cheers, Martin [0] http://marc.info/?l=openbsd-bugsm=139135208628637w=2 [1] http://marc.info/?l=openbsd-cvsm=139194643911061w=2 I might have failed to upgrade to snapshot but I still have the error. Right now, I got the snapshot install56.fs file, used it to run an upgrade and run sysmerge. I must have done something right as start_daemon isn't available anymore in /etc/rc.local but the error is still present.
Re: kernel page fault on 55-release
On 30/08/14(Sat) 11:46, ludovic coues wrote: 2014-08-30 10:53 GMT+02:00 Martin Pieuchot mpieuc...@nolizard.org: Hello Ludovic, On 28/08/14(Thu) 20:52, ludovic coues wrote: Hello, Recently, I get a kernel page fault every time I try to use the micronucleus [1] command line tool. It 's for uploading an hex file to ATtiny processor, much like arduino's avrude. The crash is pretty consistent, occuring every time I run `micronucleus --run`. I've managed to use it with success in the past on this machine with 55-release so it might be hardware related. I added a realtek wireless device since last time I've get a successful run with micronucleus. I get the following message when I run it: uvm_fault(0x81daaf001, 0x2, 2, 0, 1) - e kernel: page fault trap, code=0 Stopped at usbd_get_cdesc+035: movzwl 0x2 (%rax),%eax It's followed by the debugger prompt. I don't know how what to do from that point. I'm willing to spend time tracking the source of the problem but I have no idea of what I'm looking for. Thanks for reporting the problem. I believe this is the same issue that has been reported by Thomas Pfaff in February [0] and fixed post 5.5 [1]. Could you try a snapshot and tell me if you can still reproduce it? Cheers, Martin [0] http://marc.info/?l=openbsd-bugsm=139135208628637w=2 [1] http://marc.info/?l=openbsd-cvsm=139194643911061w=2 I might have failed to upgrade to snapshot but I still have the error. Right now, I got the snapshot install56.fs file, used it to run an upgrade and run sysmerge. I must have done something right as start_daemon isn't available anymore in /etc/rc.local but the error is still present. In this case could you send me your dmesg, the output of usbdevs -dv and the trace when the trap occurs?
FAQ4 -vs- disklabel(8) re /tmp space?
Just an FYI;- While preparing to wipe reinstall a box with a different partitioning layout, I noticed these 2 items about /tmp space: http://www.openbsd.org/faq/faq4.html#Partitioning o /tmp: 50M is usually many times what you should ever need, disklabel(8) AUTOMATIC DISK ALLOCATION /tmp 8% of disk. 120M - 4G
httpd URI leading path stripping
Hi,
I'd like to add an URI stripping option to httpd, which is similar to
apache/nginx's alias options:
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 stripped from the beginning of the request URI
before looking up the stripped-down URI at directory.
for example:
location /pub/OpenBSD/snapshots/amd64* {
root strip 4 /OpenBSD.amd64
directory auto index
}
For serving php:
location /wiki/ {
root strip 1 /dokuwiki
directory index doku.php
fastcgi socket /tmp/doku.sock
}
location /wiki/*.php {
root strip 1 /dokuwiki
fastcgi socket /tmp/doku.sock
}
location /wiki/lib/* {
root strip 1 /dokuwiki
directory no index
}
Comments? OKs?
Christopher
diff --git httpd.conf.5 httpd.conf.5
index 788d0a9..7776131 100644
--- httpd.conf.5
+++ httpd.conf.5
@@ -229,7 +229,7 @@ Enable or disable logging to
.Xr syslog 3
instead of the log files.
.El
-.It Ic root Ar directory
+.It Ic root Oo Ic strip Ar number Oc Ar directory
Set the document root of the server.
The
.Ar directory
@@ -239,6 +239,11 @@ root directory of
.Nm httpd .
If not specified, it defaults to
.Pa /htdocs .
+If the strip option is set,
+.Ar number
+path components are stripped from the beginning of the request URI before
+looking up the stripped-down URI at
+.Ar directory .
.It Ic ssl Ar option
Set the SSL configuration for the server.
These options are only used if SSL has been enabled via the listen directive.
diff --git httpd.h httpd.h
index 04b1f05..45505a1 100644
--- httpd.h
+++ httpd.h
@@ -383,6 +383,7 @@ struct server_config {
char*ssl_key_file;
u_int16_tflags;
+ u_int8_t strip;
u_int8_t tcpflags;
int tcpbufsiz;
int tcpbacklog;
diff --git parse.y parse.y
index 44cf90c..70e1cf7 100644
--- parse.y
+++ parse.y
@@ -128,12 +128,13 @@ typedef struct {
%token ACCESS AUTO BACKLOG BODY BUFFER CERTIFICATE CHROOT CIPHERS COMMON
%token COMBINED CONNECTION DIRECTORY ERR FCGI INDEX IP KEY LISTEN LOCATION
%token LOG MAXIMUM NO NODELAY ON PORT PREFORK REQUEST REQUESTS ROOT SACK
-%token SERVER SOCKET SSL STYLE SYSLOG TCP TIMEOUT TYPES
+%token SERVER SOCKET SSL STRIP STYLE SYSLOG TCP TIMEOUT TYPES
%token ERROR INCLUDE
%token v.string STRING
%token v.number NUMBER
%type v.portport
%type v.number optssl
+%type v.number optstrip
%type v.tv timeout
%type v.string numberstring
@@ -176,6 +177,10 @@ optssl : /*empty*/ { $$ = 0; }
| SSL { $$ = 1; }
;
+optstrip : /*empty*/ { $$ = 0; }
+ | STRIP NUMBER { $$ = $2; }
+ ;
+
main : PREFORK NUMBER{
if (loadcfg)
break;
@@ -333,16 +338,21 @@ serveroptsl : LISTEN ON STRING optssl port {
YYERROR;
}
} ssl
- | ROOT STRING {
- if (strlcpy(srv-srv_conf.root, $2,
+ | ROOT optstrip STRING {
+ if (strlcpy(srv-srv_conf.root, $3,
sizeof(srv-srv_conf.root)) =
sizeof(srv-srv_conf.root)) {
yyerror(document root too long);
- free($2);
+ free($3);
YYERROR;
}
- free($2);
+ free($3);
srv-srv_conf.flags |= SRVFLAG_ROOT;
+ if ($2 0 || $2 UINT8_MAX) {
+ yyerror(invalid strip number);
+ YYERROR;
+ }
+ srv-srv_conf.strip = $2;
}
| DIRECTORY dirflags
| DIRECTORY '{' dirflags_l '}'
@@ -848,6 +858,7 @@ lookup(char *s)
{ server, SERVER },
{ socket, SOCKET },
{ ssl,SSL },
+ { strip, STRIP },
{ style, STYLE },
{ syslog, SYSLOG },
{ tcp,TCP },
diff --git server_fcgi.c server_fcgi.c
index fe97be0..1d591b8 100644
--- server_fcgi.c
+++ server_fcgi.c
@@ -101,9 +101,12 @@ server_fcgi(struct httpd *env, struct client *clt)
struct fcgi_begin_request_body *begin;
char hbuf[MAXHOSTNAMELEN];
size_t
Re: usb audio interfaces
On Thu, 31 Jul 2014 12:55:47 +0200 Alexandre Ratchov a...@caoua.org wrote: On Thu, Jul 31, 2014 at 12:48:35AM +0200, Erwin Geerdink wrote: Hi, I'm considering the following usb interfaces for my audio setup: E-MU 0204 usb E-MU Tracker Pre Presonus Audiobox usb Alesis IO|2 Express Recording will be done on a Windows machine, however it would be nice if I can use it for audio playback from an OpenBSD machine as well. I found the envy(4) and emu(4) man pages but I'm still not sure whether playback would work with any of these devices. Anyone experiences or suggestions? Hi, These devices are handled by the uaudio driver, assuming they are USB class compliant (driverless ones are likely to be). Unfortunately, on OpenBSD, USB1.1 devices using isochronous transfers don't work behind USB 2.0 hubs yet. In other words USB1.1 audio cards are unlikely work on modern machines. I'd suggest you to test the cards if possible (just plug it try to play a simple .wav file). Another option, would be to get a old USB1.1 adapter and attach the USB1.1 card on it. For the records, the Alesis io2 Express appears to work fine under OpenBSD. The device has 2 channels, for each channel line out, line in and mic in are working properly (I did not test the insert jack and midi connections, but the latter do appear in dmesg). Headphone out works great too, but the mono/stereo switch does not have any effect. The monitor mix knob (direct/usb) also functions correctly. So far I'm very happy with this usb soundcard under OpenBSD, big thanks to the devs! dmesg and audioctl output is attached below. There are no mixerctl variables. $dmesg OpenBSD 5.6 (GENERIC.MP) #333: Fri Aug 8 00:20:21 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8034123776 (7661MB) avail mem = 7811473408 (7449MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (53 entries) bios0: vendor Award Software International, Inc. version F4 date 10/19/2012 bios0: Gigabyte Technology Co., Ltd. GA-78LMT-USB3 acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP MSDM HPET MCFG TAMG APIC SSDT acpi0: wakeup devices USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) SBAZ(S4) P2P_(S5) PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4) PCE9(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD FX(tm)-8320 Eight-Core Processor , 33750.19 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,PCLMUL,MWAIT,SSSE3,FMA3, CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB, LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS, XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,BMI1 cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD FX(tm)-8320 Eight-Core Processor , 3515.55 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,PCLMUL,MWAIT,SSSE3,FMA3, CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB, LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS, XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,BMI1 cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 0, core 3, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD FX(tm)-8320 Eight-Core Processor , 3515.55 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT, PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3, CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB, LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS, XOP,SKINIT,WDT,FMA4,NODEID,TBM,TOPEXT,ITSC,BMI1 cpu2: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache, 8MB 64b/line 64-way L3 cache cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu2: DTLB 64 4KB
Re: kernel page fault on 55-release
2014-08-30 11:58 GMT+02:00 Martin Pieuchot mpieuc...@nolizard.org: On 30/08/14(Sat) 11:46, ludovic coues wrote: 2014-08-30 10:53 GMT+02:00 Martin Pieuchot mpieuc...@nolizard.org: Hello Ludovic, On 28/08/14(Thu) 20:52, ludovic coues wrote: Hello, Recently, I get a kernel page fault every time I try to use the micronucleus [1] command line tool. It 's for uploading an hex file to ATtiny processor, much like arduino's avrude. The crash is pretty consistent, occuring every time I run `micronucleus --run`. I've managed to use it with success in the past on this machine with 55-release so it might be hardware related. I added a realtek wireless device since last time I've get a successful run with micronucleus. I get the following message when I run it: uvm_fault(0x81daaf001, 0x2, 2, 0, 1) - e kernel: page fault trap, code=0 Stopped at usbd_get_cdesc+035: movzwl 0x2 (%rax),%eax It's followed by the debugger prompt. I don't know how what to do from that point. I'm willing to spend time tracking the source of the problem but I have no idea of what I'm looking for. Thanks for reporting the problem. I believe this is the same issue that has been reported by Thomas Pfaff in February [0] and fixed post 5.5 [1]. Could you try a snapshot and tell me if you can still reproduce it? Cheers, Martin [0] http://marc.info/?l=openbsd-bugsm=139135208628637w=2 [1] http://marc.info/?l=openbsd-cvsm=139194643911061w=2 I might have failed to upgrade to snapshot but I still have the error. Right now, I got the snapshot install56.fs file, used it to run an upgrade and run sysmerge. I must have done something right as start_daemon isn't available anymore in /etc/rc.local but the error is still present. In this case could you send me your dmesg, the output of usbdevs -dv and the trace when the trap occurs? dmesg: OpenBSD 5.6-current (GENERIC.MP) #355: Fri Aug 29 17:01:02 MDT 2014 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4166873088 (3973MB) avail mem = 4047220736 (3859MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb190 (38 entries) bios0: vendor American Megatrends Inc. version 4.6.5 date 12/24/2013 bios0: Notebook W310CZ/CZ-T acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG SSDT HPET SSDT SSDT SSDT acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU 1037U @ 1.80GHz, 1796.23 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS 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.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) CPU 1037U @ 1.80GHz, 1795.93 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 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 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus -1 (RP02) acpiprt4 at acpi0: bus 2 (RP03) acpiprt5 at acpi0: bus 3 (RP04) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpitz0 at acpi0: critical temperature is 120 degC acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: SLPB acpibtn2 at acpi0: LID0 acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT0 not present acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: LCD0 cpu0: Enhanced SpeedStep 1796 MHz: speeds: 1800, 1700, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core 3G Host rev 0x09 vga1 at pci0 dev 2 function 0 Intel HD Graphics 2500 rev 0x09 intagp at vga1 not configured inteldrm0 at vga1 drm0 at inteldrm0 drm: Memory usable by graphics device = 2048M inteldrm0: 1366x768 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 7 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured ehci0 at
[RESOLVED] Re: Intel i354 Quad GbE network adapter failed on 5.5-RELEASE
Am 29.08.2014 um 08:11 schrieb Jonathan Gray j...@jsg.id.au: Initial support for the i347 phy was added back in March but that wasn't part of 5.5. I suspect you want something along the lines of the following patch: Yes, this patch worked (does at least initialization of em2-em5, more testing to follow). Thanks, Axel --- PGP-Key:29E99DD6 ☀ +49 151 2300 9283 ☀ computing @ chaos claudius
Re: FAQ4 -vs- disklabel(8) re /tmp space?
On 08/30/14 06:03, Craig R. Skinner wrote: Just an FYI;- While preparing to wipe reinstall a box with a different partitioning layout, I noticed these 2 items about /tmp space: http://www.openbsd.org/faq/faq4.html#Partitioning o /tmp: 50M is usually many times what you should ever need, disklabel(8) AUTOMATIC DISK ALLOCATION /tmp 8% of disk. 120M - 4G Was there a point you are trying to make? First of all, you did a stellar job of creative editing. Looking at the FULL statement from the FAQ: Most systems can get by with very modest amounts of storage here, 50M is usually many times what you should ever need, though there are a few applications which can use much, much more. I don't see these at all in conflict. A system running base applications usually uses very little /tmp space -- it's important to have, but it is small stuff that goes there. If you are creating your own partition structure, you can set it to the size you need. Maybe on an older CF-based Soekris firewall, you devote 1MB of RAM to an MFS /tmp. If you are building big ports, maybe you want gigabytes of /tmp. If you are running an internal CVS server and don't bother to chroot it, you may not only want a lot of /tmp space, but with the number of inodes cranked up. If you are letting the installer make the decision, the installer is going to go big, to keep you from whining when you want to use /tmp for something that wasn't anticipated. If you have great gobbs of disk space, go ahead, crank it up and use /tmp for other things, use it for your own temporary storage space, space for shuttling files between users, etc. By its nature, use of /tmp can expand as space is available. Nick.
Alix 3D3 disconnects from network after random amount of time
Hello, My recently acquired PC Engines Alix 3D3 [1] board running OpenBSD 5.5-stable suddenly disconnects from my local network after a random amount of time, typically 15-60 minutes. This happens consistently while there is a low but constant amount of network traffic (e.g. soundcard is used by a remote machine using sndiod). Re-initializing the interface and running dhclient restores the connection: $ sudo ifconfig vr0 down $ sudo ifconfig vr0 up $ sudo dhclient vr0 The Alix is connected to a Wireless Gigabit Dualband 300N prefab router running dhcp. The router has been reliable so far and other machines do not suffer from any disconnections. Since this is a second-hand device I cannot rule out any hardware problems, although network connectivity is fine until it breaks. I will try some Linux distro soon and see if the same problem occurs. Searching the mailing lists does not show any similar issues. Below is some output from the Alix after disconnection while running tcpbench, not sure if it's useful: dmesg, ifconfig, netstat -i, netstat -s and tcpbench. [1] http://www.pcengines.ch/alix3d3.htm $ dmesg OpenBSD 5.5 (GENERIC) #0: Fri Apr 25 15:04:32 CEST 2014 r...@stable-55-i386.mtier.org:/binpatchng/work-binpatch55-i386/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586-class) 499 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW real mem = 259219456 (247MB) avail mem = 242675712 (231MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 02/11/09, BIOS32 rev. 0 @ 0xfaf90 apm0 at bios0: Power Management spec V1.2 (slowidle) pcibios0 at bios0: rev 2.1 @ 0xf/0xdfb4 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf20/144 (7 entries) pcibios0: bad IRQ table checksum pcibios0: PCI BIOS has 7 Interrupt Routing table entries pcibios0: PCI Exclusive IRQs: 5 10 11 pcibios0: no compatible PCI ICU found pcibios0: Warning, unable to fix up PCI interrupt routing pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xc/0x8000 0xc8000/0xa800 0xef000/0x1000! cpu0 at mainbus0: (uniprocessor) mtrr: K6-family MTRR support (2 registers) amdmsr0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x33 vga1 at pci0 dev 1 function 1 AMD Geode LX Video rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES vr0 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 11, address 00:0d:b9:2b:97:28 ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 glxpcib0 at pci0 dev 15 function 0 AMD CS5536 ISA rev 0x03: rev 3, 32-bit 3579545Hz timer, watchdog, gpio, i2c gpio0 at glxpcib0: 32 pins iic0 at glxpcib0 maxtmp0 at iic0 addr 0x4c: lm86 pciide0 at pci0 dev 15 function 2 AMD CS5536 IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: TS4GCF133 wd0: 1-sector PIO, LBA, 3823MB, 7831152 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 ignored (disabled) auglx0 at pci0 dev 15 function 3 AMD CS5536 Audio rev 0x01: irq 11, CS5536 AC97 ac97: codec id 0x414c4770 (Avance Logic ALC203 rev 0) ac97: codec features headphone, 20 bit DAC, 18 bit ADC, No 3D Stereo audio0 at auglx0 ohci0 at pci0 dev 15 function 4 AMD CS5536 USB rev 0x02: irq 5, version 1.0, legacy support ehci0 at pci0 dev 15 function 5 AMD CS5536 USB rev 0x02: irq 5 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1 isa0 at glxpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbdprobe: reset response 0xfa pcppi0 at isa0 port 0x61 spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 AMD OHCI root hub rev 1.00/1.00 addr 1 uaudio0 at uhub1 port 1 configuration 1 interface 0 Alesis io|2 rev 1.10/1.01 addr 2 uaudio0: audio rev 1.00, 0 mixer controls audio1 at uaudio0 umidi0 at uhub1 port 1 configuration 1 interface 3 Alesis io|2 rev 1.10/1.01 addr 2 umidi0: (genuine USB-MIDI) umidi0: out=1, in=1 midi0 at umidi0: USB MIDI I/F uhub2 at uhub1 port 2 ALCOR USB Hub 2.0 rev 2.00/7.02 addr 3 uhidev0 at uhub2 port 2 configuration 1 interface 0 Primax Electronics USB Optical Mouse rev 2.00/2.00 addr 4 uhidev0: iclass 3/1 ums0 at uhidev0: 3 buttons, Z dir wsmouse0 at ums0 mux 0 uhidev1 at uhub2 port 4 configuration 1 interface 0 USB USB Keykoard rev 1.10/1.10 addr 5 uhidev1: iclass 3/1 ukbd0 at uhidev1: 8 variable keys, 6 key codes wskbd0 at ukbd0: console keyboard, using wsdisplay0 uhidev2 at uhub2 port 4 configuration 1 interface 1 USB USB Keykoard rev 1.10/1.10 addr 5 uhidev2: iclass 3/0, 2 report ids uhid0 at uhidev2 reportid 1: input=2, output=0, feature=0 uhid1 at uhidev2 reportid 2: input=1,
Re: FAQ4 -vs- disklabel(8) re /tmp space?
On 2014-08-30 Sat 08:19 AM |, Nick Holland wrote: Was there a point you are trying to make? No: Just an FYI;-
nginx in current.html
The line rcctl enable nginx in current.htl should probably read rcctl enable enginx because /etc/rc.d/enginx is what gets installed.
Re: nginx in current.html
On Sat, Aug 30, 2014 at 05:29:48PM +0200, Jan Stary wrote: The line rcctl enable nginx in current.htl should probably read rcctl enable enginx because /etc/rc.d/enginx is what gets installed. Not if you have an up-to-date pkg. (not avail in snapsnots yet) -- Antoine
openbgpd rdomain/rtable (vrf-lite)
Hello misc@,
I'd like to set up bgpd with multiple routing tables, a la vrf-lite
(ie without mpls and mp-bgp).
What works:
- peering within a rtable/rdomain
- receiving the routes
What doesn't work:
- nexthop is never validated
- routes are never installed in fib
Configuration is pretty straitforward:
# cat bgpd.conf
AS 64751
router-id 172.22.151.130
listen on 172.22.151.130 # loopback
listen on 172.22.151.251 # interface towards peer
rtable 10
group ibgp peering AS64751 {
remote-as 64751
neighbor 172.22.151.245 {
descr beta
announce self
}
}
bgpd is started as such:
route -n -T10 exec bgpd -d -v -f /etc/bgpd/bgpd.conf
Peering gets up, and routes received:
# bgpctl -n show sum
Neighbor ASMsgRcvdMsgSent OutQ Up/Down State/PrfRcvd
172.22.151.245 64751 10851 6373 0 2d05h05m338
Routes are received in rtable 0:
# bgpctl show rib in | head
flags: * = Valid, = Selected, I = via IBGP, A = Announced, S = Stale
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
I 10.0.0.0/16 172.22.151.245 100 0 64734.14918
64734.12596 65112 65530 i
I 10.1.0.0/16 172.22.151.245 100 0 64734.14918
64734.12596 65112 65530 i
I 10.8.0.0/16 172.22.151.245 100 0 64734.12699
1.10582 65053 i
I 10.11.0.0/18 172.22.151.245 100 0 64828 64609 i
I 10.11.64.0/18172.22.151.245 100 0 64828 1.10567 1.10594 i
I 10.15.0.0/16 172.22.151.245 100 0 64828 1.10604 65079 i
And indeed, 172.22.151.245 is not reachable in rtable0.
If I use rde rib foo no evaluate, routes are put in the 'foo' rib,
but still not installed.
If I use the rde rib foo table 10, I get the following error:
'/etc/bgpd/bgpd.conf:20: rtable 10 does not belong to rdomain 0'
I tried to use 'rdomain 10' in the config file, but that looks very
mpls-oriented (mp-bgp peering in GRT, which works fine btw).
Have I missed something, or am I asking for something currently unsupported?
Thanks, and sorry for the long post,
--
petrus
Re: Automated PXE install with Serva (updated)
On Sat, Aug 30, 2014 at 01:06:11AM -0700, Patrick Masotta wrote: Hi, I'm installing install55.iso with Serva. Serva is an automated PXE server that let us install many OSs (including OpenBSD) from a menu. It is interesting to know that even when there are some rough edges OpenBSD is today the only BSD distro capable of being installed by an automated PXE server. I'd like to share with you guys those rough edges and see if they can probably be addressed in future releases. The idea behind Serva is that the distro's ISO directly becomes part of Serva's repository when its content is directly copied under a certain directory controlled by the PXE server. Problems: 1) The PXE install process asks for the file .\5.5\amd64\index.txt but the distro names it .\5.5\amd64\TRANS.TBL; probably just renaming this file or adding .\5.5\amd64\index.txt to the distro will solve the issue. 2) The PXE install process looks after .\5.5\amd64\SHA256.sig but the distro includes .\5.5\amd64\SHA256 ; I think the distro should include SHA256.sig or both. 3) The PXE install process needs .\5.5\amd64\etc\boot.conf but the distro has not .\etc\boot.conf ; probably it would be a good idea adding a default .\5.5\amd64\etc\boot.conf in the distro's ISO containing i.e. a single line like boot bsd.rd 4) OpenBSD automated installs look after /install.conf; this is an absolute path and that is a deal breaker when it comes to multi OS PXE servers like Serva; then why not alternative look for that file in ./5.5/amd64/etc/install.conf in the same way the install now looks for ./5.5/amd64/etc/boot.conf ? See http://thread.gmane.org/gmane.os.openbsd.misc/213697 5) Automated PXE servers usually use configuration files that deal with the distro ISO directory structure. It is never a good idea adopting a differentiated structure based in i.e. architecture. That forces automated tools to deal with a different script for every architecture. .\5.5\amd64\ .\5.5\i386\ OpenBSD installer is simple, you can install for example i386 while booting amd64 kernel and just extract sets... etc. It is always a better idea to have a constant directory structure like .\5.5\bin\ with an empty file at root with its name indicating the corresponding architecture 6) OpenBSD automated installs require the repository url or IP; on a PXE environment that IP is very often the parameter next-server gathered from the initial PXE DHCP transaction. It would be very handy having a wildcard like %next-server% that can be interpreted when parsing install.conf. This way we do not have to manually add a different repository IP for every different PXE scenario I think if some of these issues can be addressed OpenBSD PXE install capabilities will be greatly improved not just only for Serva but for every PXE server out there. You guys can see here the ServaAsset.inf required to PXE boot OpenBSD and other non-windows assets. http://vercot.com/~serva/an/NonWindowsPXE3.html And you probably didn't mention problem with auto_install as 'filename' :) See http://devio.us/~jirib/pxelinux-openbsd.html j.
Re: Help, please, understanding AHCI error on amd64
On 08/29/2014 06:15 PM, Chris Cappuccio wrote: 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. It depends a lot on how you intend to use them: how annoyed you get if you have to replace one, how annoyed you get if the array goes off-line or goes into degraded mode when a drive performs its most extensive bad block recovery, how annoyed you get when the RAID controller mistakenly takes a drive off line, and how much money and effort you're willing to put into the case in which you mount the drives. You could set the RAID timer to wait for multiple minutes before declared the drive offline. That would effectively put the RAID in degraded mode during that time - writing would be disabled. You might be able to disable the drive's extended error recovery with an internal parameter setting, requiring the RAID controller to do bad block remapping but the drive will never take a long time to respond. That would minimize the time that the RAID was in degraded mode or off line. If you did neither, then when a drive did extended error recovery, the controller would declare the drive off-line. You would have to intervene and figure out whether the drive was really bad or that you just needed to reset the controller's status. The controller firmware is unlikely to do that for you. You could install the drives in a well-cooled vibration-isolating case. That would minimize seek errors caused by vibration. excess spindle bearing wear, and premature failure due to overheating. The consumer drives are not designed to read, write, and seek continuously. Consumer multiple-drive bays and boxes usually have no vibration isolation and poor cooling. Given the above precautions, a consumer drive could work very well. I had several very premature drive failures using consumer drives in a consumer multi-bay case. Since then I've always mounted drives with considerable space between them and have had no failures. YMMV Geoff Steckel
Re: pfsync and trunk
On Saturday, August 30, 2014 8:27:24 AM Tony Sarendal wrote: Good morning, I'm having issues with pfsync on trunk interfaces, although I suspect it to snip 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. snip pfSense is FreeBSD-based. not OpenBSD-based... different versions of pf between OpenBSD and FreeBSD -- Chuck Burns Audemus Jura Nostra Defendere
Re: pfsync and trunk
And what does OP's message have to do with pfSense ??? (especially since he's clearly indicating currently supported OpenBSD versions 5.4 and 5.5 near the bottom...) On 30 Aug 2014 at 14:22, Chuck Burns wrote: On Saturday, August 30, 2014 8:27:24 AM Tony Sarendal wrote: Good morning, I'm having issues with pfsync on trunk interfaces, although I suspect it to snip 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. snip pfSense is FreeBSD-based. not OpenBSD-based... different versions of pf between OpenBSD and FreeBSD -- Chuck Burns Audemus Jura Nostra Defendere
Problem with cwm and tabbed
I encountered a problem either with cwm or tabbeb (http://tools.suckless.org/tabbed/). If I use cwm as my window manager and start tabbed with an XEmbed supported application like xterm, surf or st (e.g. tabbed xterm -into) and then I resize the window of tabbed. Before doing something else with the application inside tabbed I try to close the instance with CTRL+Q (which is inherited from tabbed to close the application). The result is cwm crashing and i'll be greeted by the xdm login window. Unfortunately there is no relevant (imho) output to the Xorg logs. Does the problem exist for others and how can I further debug it?
Re: Problem with cwm and tabbed
There is a problem in OpenBSD 5.5 cwm with using pointers like cc-group-shortcut without testing cc-group for being NULL This is (should be) fixed in current. It leads to crashes of cwm (in 5.5) but may be not the cause for what happens on your system. (Had been very annoying for me since it always had happend during beamer presentations at work :-) --Carsten
Problem with cwm and tabbed
I encountered a problem either with cwm or tabbeb (http://tools.suckless.org/tabbed/). If I use cwm as my window manager and start tabbed with an XEmbed supported application like xterm, surf or st (e.g. tabbed xterm -into) and then I resize the window of tabbed. Before doing something else with the application inside tabbed I try to close the instance with CTRL+Q (which is inherited from tabbed to close the application). The result is cwm crashing and i'll be greeted by the xdm login window. Unfortunately there is no relevant (imho) output to the Xorg logs. Does the problem exist for others and how can I further debug it?
Re: athn panic on 5.5-stable
On Sat, Aug 30, 2014 at 08:28:09AM +, Stefan Sperling wrote: Beware, the ar9003 parts of athn are somewhat broken and unfinished. Ah, I see. Damn, I really thought I had a chance with this card ;) That said, can you try this? Index: ar9003.c === RCS file: /cvs/src/sys/dev/ic/ar9003.c,v retrieving revision 1.30 diff -u -p -r1.30 ar9003.c --- ar9003.c 22 Jul 2014 13:12:11 - 1.30 +++ ar9003.c 30 Aug 2014 08:22:26 - @@ -165,6 +165,8 @@ ar9003_attach(struct athn_softc *sc) struct athn_ops *ops = sc-ops; int error; + sc-ngpiopins = 16; + /* Set callbacks for AR9003 family. */ ops-gpio_read = ar9003_gpio_read; ops-gpio_write = ar9003_gpio_write; Unfortunately that didn’t change the outcome. I’ll hook up the console a little later to see if the error is any different, but there’s still a panic. Cheers, Mark
Re: maybe OT 10 year anniversay of Chuck Yerkes death
On Thu, 28 Aug 2014, Craig R. Skinner wrote: On 2014-08-27 Wed 17:21 PM |, Diana Eichert wrote: I'm writing this post to remember Chuck Yerkes, He must've made quite an impact for you to respect him every year. Cool. He was very helpful to folks on more than this list. I was in the middle of an email thread with him related to Sun h/w when I saw the post re: his death. It was a very sad moment. g.day
