Re: route6d bug
Hi, is there anyone out there running route6d without any issues (on OpenBSD releases 4.3)? ;) Recommendations for far better compact alternatives for IPv6 prefix delegation route announcement exchange(s) within a network cloud of redundant (carp) default routers and CPEs with rare flash memory are also welcome. :) I'd like to implement native IPv6 support for our CPEs, but dynamic prefix delegation and routing seem to be a pain without using IPv4 tunnels, yet. -Florian Florian Fuessl f...@... wrote: Hi, current route6d does not add advertised RipNG routes of other systems to the routing table. This problem seems to go back to 2008, as older OpenBSD releases do also suffer from this problem, here. Using route6d build from Jul. 3, 2007 does add advertised RipNG routes to the kernel routing table, but does not delete them on exit; at least if running a recent kernel. :-( Any hints how to patch this problem? -Florian
route6d bug
Hi, current route6d does not add advertised RipNG routes of other systems to the routing table. This problem seems to go back to 2008, as older OpenBSD releases do also suffer from this problem, here. Using route6d build from Jul. 3, 2007 does add advertised RipNG routes to the kernel routing table, but does not delete them on exit; at least if running a recent kernel. :-( Any hints how to patch this problem? -Florian
Re: Would a consolidated greytrapping list be useful?
Hi Peter, -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Peter N. M. Hansteen [...] So I'm considering setting up a consolidated greytrap list to supplement uatraps and others, if other greytrappers out there are willing to share their data. I think sharing the greytrap results is a good idea if the sources are reliable, up-to-date and stable :) My list is available at [1], with a the list of trap addresses and some description at [2], with a policy statement of sorts at [3] (I imagine I would require a similar statement from any participants), and various field notes available at my blog (see the signature). Would something like this be useful? Any comments and feedback (including why this would be a monumentally stupid idea) welcome. I've had about 2000 hits using your traplist here, today: [...]:~ $ grep bsdly /var/log/spamd | wc -l 2175 So I guess it's no bad idea to cross-link some more trap lists in order to get even better results. Therefore I've also published my trap list under http://degnet.de/~flo/antispam/degnet.traplist It's updated twice an hour and currently has about 35k trapped entries. - Florian
Re: Would a consolidated greytrapping list be useful?
-Original Message- From: owner-m...@[...] On Behalf of Bob Beck [...] Exactly what are yo consolidating here peter? If it is blacklists or traplists from various sources, I think this may do people a disservice. The problem if you are aggregating the traplists is that users don't have a clue where stuff is coming from. They know the person is trapped because they are in the bsdly traplist - why the host is there they don't know, or the key being, they don't know who actually added them and why they get on there. right now, if they get on uatraps, you know (if you were downloading it seperately) where the host was blocked and why. Obscuring the source of the trap just makes life more difficult for the admins who occasionally need to deal with a host that gets trapped. Thx. Bob, that's the crucial point: Therefore it's probably the best to make available the own trap list, so that everybody itself can decide to use the results or not. 2009/10/4 Peter N. M. Hansteen pe...@bsdly.net: [...] -Florian
Re: Defending OpenBSD Performance
Hi Henning, -Original Message- From: owner-m...@[...] on Behalf Of Henning Brauer Sent: Tuesday, September 15, 2009 2:39 PM Subject: Re: Defending OpenBSD Performance * Nick n...@holland-consulting.net [2009-09-15 13:52]: [...] i have a bgp machine forwarding 800MBit/s of real world generic internet traffic. can handle at least twice that. enough of a benchmark? what hardware (CPU, NICs, MEM) and OpenBSD release (i386, GENERIC?) are you running on your bgp machine(s)? -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam -Florian
sd0(ciss0:0:0): cannot allocate scsi xs
Hi, one of our OpenBSD 4.2 HP ProLiant machines hanged up today repeating the following messages: sd0(ciss0:0:0): cannot allocate scsi xs sd0: not queued, error 12 sd0(ciss0:0:0): cannot allocate scsi xs sd0: not queued, error 12 sd0(ciss0:0:0): cannot allocate scsi xs sd0: not queued, error 12 [...] After a cold reboot all seems to be fine, again. Any ideas what may cause this pain are welcome :) -Florian Kernel is GENERIC 4.2, recompiled with patches up to 014, dmesg below: OpenBSD 4.2 (GENERIC) #3: Tue Aug 5 14:07:14 CEST 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 1073291264 (1023MB) avail mem = 1030938624 (983MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xec000 (77 entries) bios0: vendor HP version P51 date 04/26/2006 bios0: HP ProLiant DL380 G4 acpi at mainbus0 not configured cpu0 at mainbus0: (uniprocessor) cpu0: Intel(R) Xeon(TM) CPU 3.00GHz, 3000.50 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLU SH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xT PR,LONG cpu0: 2MB 64b/line 8-way L2 cache pci0 at mainbus0 bus 0: configuration mode 1 pchb0 at pci0 dev 0 function 0 Intel E7520 MCH rev 0x0c ppb0 at pci0 dev 2 function 0 Intel MCH PCIE rev 0x0c pci1 at ppb0 bus 2 ppb1 at pci1 dev 0 function 0 Intel PCIE-PCIE rev 0x09 pci2 at ppb1 bus 3 bge0 at pci2 dev 1 function 0 Broadcom BCM5704C rev 0x10, BCM5704 B0 (0x2100): irq 5, address 00:18:fe:72:82:73 brgphy0 at bge0 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 bge1 at pci2 dev 1 function 1 Broadcom BCM5704C rev 0x10, BCM5704 B0 (0x2100): irq 5, address 00:18:fe:72:82:72 brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 ppb2 at pci1 dev 0 function 2 Intel PCIE-PCIE rev 0x09 pci3 at ppb2 bus 4 ciss0 at pci3 dev 3 function 0 Compaq Smart Array 64xx rev 0x01: irq 5 ciss0: 1 LD, HW rev 1, FW 2.76/2.76 scsibus0 at ciss0: 1 targets sd0 at scsibus0 targ 0 lun 0: HP, LOGICAL VOLUME, 2.76 SCSI3 0/direct fixed sd0: 69459MB, 8854 cyl, 255 head, 63 sec, 512 bytes/sec, 142253280 sec total ppb3 at pci0 dev 6 function 0 Intel MCH PCIE rev 0x0c pci4 at ppb3 bus 5 ppb4 at pci4 dev 0 function 0 Intel PCIE-PCIE rev 0x09 pci5 at ppb4 bus 6 em0 at pci5 dev 1 function 0 Intel PRO/1000MT (82546GB) rev 0x03: irq 5, address 00:04:23:d6:cc:40 em1 at pci5 dev 1 function 1 Intel PRO/1000MT (82546GB) rev 0x03: irq 5, address 00:04:23:d6:cc:41 ppb5 at pci4 dev 0 function 2 Intel PCIE-PCIE rev 0x09 pci6 at ppb5 bus 10 em2 at pci6 dev 1 function 0 Intel PRO/1000MT (82546GB) rev 0x03: irq 5, address 00:04:23:ce:cb:74 em3 at pci6 dev 1 function 1 Intel PRO/1000MT (82546GB) rev 0x03: irq 5, address 00:04:23:ce:cb:75 uhci0 at pci0 dev 29 function 0 Intel 82801EB/ER USB rev 0x02: irq 5 uhci1 at pci0 dev 29 function 1 Intel 82801EB/ER USB rev 0x02: irq 5 uhci2 at pci0 dev 29 function 2 Intel 82801EB/ER USB rev 0x02: irq 5 uhci3 at pci0 dev 29 function 3 Intel 82801EB/ER USB rev 0x02: irq 5 ehci0 at pci0 dev 29 function 7 Intel 82801EB/ER USB2 rev 0x02: irq 5 usb0 at ehci0: USB revision 2.0 uhub0 at usb0: Intel EHCI root hub, rev 2.00/1.00, addr 1 ppb6 at pci0 dev 30 function 0 Intel 82801BA AGP rev 0xc2 pci7 at ppb6 bus 1 vga1 at pci7 dev 3 function 0 ATI Rage XL rev 0x27 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) Compaq iLO rev 0x01 at pci7 dev 4 function 0 not configured Compaq iLO rev 0x01 at pci7 dev 4 function 2 not configured pcib0 at pci0 dev 31 function 0 Intel 82801EB/ER LPC rev 0x02 pciide0 at pci0 dev 31 function 1 Intel 82801EB/ER IDE rev 0x02: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility atapiscsi0 at pciide0 channel 0 drive 0 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0: TSSTcorp, CD-ROM TS-L162C, N204 SCSI0 5/cdrom removable cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 disabled (no drives) usb1 at uhci0: USB revision 1.0 uhub1 at usb1: Intel UHCI root hub, rev 1.00/1.00, addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2: Intel UHCI root hub, rev 1.00/1.00, addr 1 usb3 at uhci2: USB revision 1.0 uhub3 at usb3: Intel UHCI root hub, rev 1.00/1.00, addr 1 usb4 at uhci3: USB revision 1.0 uhub4 at usb4: Intel UHCI root hub, rev 1.00/1.00, addr 1 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 dkcsum: sd0 matches BIOS drive 0x80 root on sd0a swap on sd0b dump on sd0b WARNING: / was not properly unmounted
Re: Performance issues with the DNS patch?
Hi, is there a particular reason, why you have to use bind as resolver? If not, I would try out running a DNS-recursor (PowerDNS-recursor, djbdns, ...) which may offer more performance and maybe less pain in the future ;) -Florian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J Duke Sent: Sunday, July 27, 2008 12:13 AM To: misc@openbsd.org Subject: Performance issues with the DNS patch? I wonder is anyone is seeing performance issues with the patched DNS in the late snapshots? I installed the July 22 snapshot on our DNS servers, which handle a pretty heavy load of lookups, mostly for anti-spam action. It was running at 45% or higher cpu utilization after the July 22 snapshot was installed. We run a couple of Ironport boxes, that handle about 200k emails per hour. They use the OpenBSD DNS servers to look up the sending IPs as a first defense against spammers, and drop about 98% of the inbound mail. With the snapshot installed the traffic went down to 70k per hour and people started complaining of DNS lookup failures for random sites. I moved back to an earlier version of OpenBSD on the DNS server, and the Ironport traffic went up to normal, and the DNS lookup failures stopped. Cpu utilization went back down to around 9%. But I'm vulnerable. I realize that the whole fix to this DNS cache poisoning is to have random ports and random query ids, and that generating good, strong, random numbers costs cpu cycles and time. Has anyone else noticed the performance hit? Anything that I can do? Particularly I am open to any suggestions on commands that would help identify if that is really the problem, systat, vmstat, etc. The server was beefy enough, and had been doing the job for months before the upgrade: OpenBSD 4.2-current (GENERIC) #593: Mon Dec 10 13:23:15 MST 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Xeon(TM) CPU 3.20GHz (GenuineIntel 686-class) 3.21 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36 ,CF LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT- ID,CX16,xTPR real mem = 1073053696 (1023MB) avail mem = 1029713920 (982MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 10/20/04, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @ 0xfa910 (75 entries) bios0: vendor Dell Computer Corporation version A00 date 10/20/2004 bios0: Dell Computer Corporation PowerEdge SC1425 [...] em0 at pci2 dev 4 function 0 Intel PRO/1000MT (82541GI) rev 0x05: irq 11, i address xx:xx:xx:xx:xx:xx Thanks for a great OS! And yes, I usually run snapshots, have for years, love it, and we buy plenty of CDs of each version..
Re: spamd-setup hangup/timeout settings
Hi, sorry for reopening/closing this old case; this msg. is just for notice: Increasing kern.maxclusters has solved the problem here. :) Just in case anyone has pain with the same problem. -Florian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Florian Fuessl Sent: Sunday, January 06, 2008 12:14 PM To: misc@openbsd.org Subject: spamd-setup hangup/timeout settings Hi, I'm running spamd-setup via regular cronjob every 20 minutes. Sometimes the spamd-setup process seems to hang and does not finish within this period, although all black- and whitelists are local files. Is there a way define timeouts for tasks of spamd-setup? What solution is recommended for this case? Killing the running spamd-setup task(s) before starting a new one? -Florian
Re: spamd-setup hangup/timeout settings
Peter N. M. Hansteen [EMAIL PROTECTED] wrote: Florian Fuessl [EMAIL PROTECTED] writes: Increasing kern.maxclusters has solved the problem here. :) It would be interesting to hear a bit more about which values you have tried and to what effect. Doubling the default (6144) should be far enough; I did setup the value 128000 which is obviously exaggerated but seems to works fine here: ~ # netstat -m 2766 mbufs in use: 2246 mbufs allocated to data 515 mbufs allocated to packet headers 5 mbufs allocated to socket names and addresses 1675/6152/128000 mbuf clusters in use (current/peak/max) 14460 Kbytes allocated to network (27% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines
Re: spamd-setup hangup/timeout settings
Strange thing here is that spamd-setup sometimes hangs although all spamd.conf entries point to local copied traplists downloaded by a separate cron process. :-| -Flo -Original Message- Of Mike Erdely Sent: Wednesday, January 09, 2008 7:54 PM You could point to a local copy (/var/db/traplist.gz) in spamd.conf and download it in a separate cron process. -ME
Re: spamd-setup hangup/timeout settings
Frank Bax wrote: My spamd-setup always takes 20-30 minutes on two servers (4.1 and 4.2). This is not normal? When I run it manually; most of the time is spent downloading traplist.gz This morning, I changed the crontab time /usr/libexec/spamd-setup -d 4.1 runtimes (minutes): 39, 10, 27, 32 4.2 runtimes (minutes): 23, 29, 22, 22 The runtime here is usually only a few seconds: [...] time /usr/libexec/spamd-setup -d blacklist becks 110141 entries blacklist nixspam 39962 entries blacklist sorbs-zombie 102 entries blacklist sorbs-dul 277194 entries whitelist sorbs-dul-white 357120 entries 0m13.34s real 0m5.80s user 0m2.21s system That's why it's so strange, that sometimes spamd-setup process hangs and does not quit within 20 minutes. :- Any ideas, how to handle that case correctly or how to debug that case? -Florian
spamd-setup hangup/timeout settings
Hi, I'm running spamd-setup via regular cronjob every 20 minutes. Sometimes the spamd-setup process seems to hang and does not finish within this period, although all black- and whitelists are local files. Is there a way define timeouts for tasks of spamd-setup? What solution is recommended for this case? Killing the running spamd-setup task(s) before starting a new one? -Florian
Re: spamd-setup hangup/timeout settings
Peter N. M. Hansteen [EMAIL PROTECTED] wrote: I'm running spamd-setup via regular cronjob every 20 minutes. Sometimes the spamd-setup process seems to hang and does not finish within this period, although all black- and whitelists are local files. I would try to figure out why the process stalls. My first hunch when something network related suddenly takes a lot longer than usual is to check that name resolution is actually working. Also, it is worth try spamd-setup with -d, then it provides a little more data on what actually happens. That was also my first thought. That's why I reconfigured spamd-setup to use local files only and fetch the needed files before execution with wget and a useful timeout. The problem only occurs rarely after spamd-setup processed all black- and whitelists while trying to update the spamdb database (or maybe spamd-white pf-table). spamd-setup with -d option does not show any details after importing the last whitelist. :- Killing spamd-setup also quits the spamd process. -Florian
Re: multipath routing with OpenBGPD
AS-AAS-B -++---+--- || | || | X bgpA1 X bgpA2 X bgpB1 _++___+___ Housing A +Housing B | GigE | X bgpC1 and bgpC2 __+___ Housing C It's only a small network setup. Housing C is the source and destination of almost all traffic to AS-C. The BGP-routers A1, A2, B1, C1 and C2 are all part of AS-C and directly linked via iBGP. bgpB1 is only peering to AS-B and backup upstream. bgpA1 and A2 are the main upstream peering points. bgpC1 is main router, bgpC2 is backup router @ Housing C running OpenBSD. I though setting Multipath for the incoming routes from bgpA1 and A2 on bgpC1 and C2 would be a kind feature for testing. -Florian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Sarendal Sent: Saturday, November 03, 2007 2:31 PM To: misc@openbsd.org Subject: Re: multipath routing with OpenBGPD On 11/3/07, Florian Fuessl [EMAIL PROTECTED] wrote: Hi Gregory, we have multiple redundant FE upstream peerings to the same AS. So I guess the best solution would be in our case to let the upstream provider assign different community flags for packets passing each FE line which we can use for outgoing route preference decisions. Other ideas are welcome ;-) I hope you mean communites on prefixes, and even in that case what can the provider do that you can't ? What does your topology look like ? /Tony
Re: multipath routing with OpenBGPD
Hi Gregory, we have multiple redundant FE upstream peerings to the same AS. So I guess the best solution would be in our case to let the upstream provider assign different community flags for packets passing each FE line which we can use for outgoing route preference decisions. Other ideas are welcome ;-) -Florian -Original Message- From: Gregory Edigarov [mailto:[EMAIL PROTECTED] Sent: Thursday, November 01, 2007 4:51 PM To: Florian Fuessl Subject: Re: multipath routing with OpenBGPD Florian Fuessl wrote: Hi, Has anyone already tried to use multipath routing for equal BGP4 peer routes or are there any plans to implement this feature into OpenBGPD? What's your network design? I suspect, what you want called BGP based load balancing, and that is quite a usual setup, -- With best regards, Gregory Edigarov
multipath routing with OpenBGPD
Hi, Has anyone already tried to use multipath routing for equal BGP4 peer routes or are there any plans to implement this feature into OpenBGPD? -Florian
Re: intel pro/1000 PT PF
Hi Kai, I just noticed that I've to recall my last mail to this topic: We are using Intel PRO/1000 MT (PCI-X) dual and quad port cards here and these work fine on both i386 and amd64 with 4.1. -Florian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kai Mosebach Sent: Tuesday, October 30, 2007 10:19 PM To: Florian Fuessl Cc: 'Michel Le Cocq'; misc@openbsd.org Subject: Re: intel pro/1000 PT PF Does this also apply to amd64 ? Thanks Kai Hello all, I just wanted to know if the network cards : - - intel pro/1000 PT quad port Works fine here with 4.1 :)
spamd and MailEnable mta problems
Hi,
MailEnable seem to have problems connecting to OpenBSD spamd in greylisting
mode and stuttering enabled.
MailEnable is unable to detect the 220 . string and timeouts the
connection to spamd after a few seconds with a connection error.
Patched now spamd to send the 220 . as a complete string:
@@ -910,7 +910,7 @@
cp-sr = 1;
else
cp-sr = 0;
- n = write(cp-fd, cp-op, (one cp-stutter) ? 1 :
cp-ol);
+ n = write(cp-fd, cp-op, (one cp-stutter) ? 4 :
cp-ol);
if (n == 0)
closecon(cp);
else if (n == -1) {
Guess this is a MailEnable bug, but maybe anyone has the possibility to test
if this patch helps to workaround the problem.
- Florian
Re: pfctl: Cannot allocate memory
Hi, try adding the following lines to your /etc/pf.conf and reload with pfctl -f /etc/pf.conf set limit tables 5000 # default 1000 set limit table-entries 500 # default 10 Guess this should solve your problem... - Florian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of M... Sent: Friday, February 23, 2007 2:12 PM To: misc@openbsd.org Subject: pfctl: Cannot allocate memory Hello. I've been running spamd with greylisting for a few weeks. Today, I am getting 'pfctl: Cannot allocate memory' notifications. OpenBSD 4.0 GENERIC#1107 i386 load averages: 0.18, 0.23, 0.24 08:04:24 62 processes: 61 idle, 1 on processor CPU states: 0.3% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.7% idle Memory: Real: 23M/69M act/tot Free: 168M Swap: 0K/102M used/tot # vmstat -m Memory statistics by bucket size Size In Use Free Requests HighWater Couldfree 16 4988 1037225844521280 792 32 290 11181672745 640 93 64 1211133 148714 320 0 128 757 75 69589 160 0 256 186 38 48794 80 0 512 161 31 48241 40 1 1024 628 60 65101 20 15049 2048 78 12 560411 10 323719 4096 31 4314 5 0 81927 0 7 5 0 163842 0 2 5 0 327684 0 4 5 0 Memory usage type by bucket size Size Type(s) 16 devbuf, pcb, routetbl, ifaddr, sysctl, vnodes, UFS mount, sem, dirhash, in_multi, exec, xform_data, VM swap, UVM amap, UVM aobj, USB, temp 32 devbuf, pcb, routetbl, ifaddr, vnodes, UFS mount, sem, dirhash, proc, VFS cluster, ether_multi, xform_data, VM swap, UVM amap, USB, packet tags, temp 64 devbuf, pcb, routetbl, ifaddr, sem, dirhash, in_multi, pfkey data, UVM amap, USB, NDP, temp 128 devbuf, routetbl, ifaddr, sysctl, vnodes, dirhash, ttys, exec, UVM amap, USB, USB device, NDP 256 devbuf, routetbl, ifaddr, ioctlops, vnodes, shm, VM map, dirhash, file desc, proc, NFS srvsock, NFS daemon, newblk, UVM amap, USB, temp 512 devbuf, pcb, ifaddr, ioctlops, mount, UFS mount, shm, dirhash, ttys, exec, UVM amap, USB device, temp 1024 devbuf, ioctlops, namecache, proc, ttys, exec, UVM amap, UVM aobj, crypto data, temp 2048 devbuf, ifaddr, ioctlops, UFS mount, pagedep, VM swap, UVM amap, temp 4096 devbuf, ioctlops, UFS mount, MSDOSFS mount, VM swap, UVM amap, temp 8192 devbuf, NFS node, namecache, UFS quota, UFS mount, ISOFS mount, inodedep 16384 devbuf, namecache 32768 devbuf Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) devbuf 1016 691K703K 38031K 554212 0 0 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768 pcb79 7K 7K 38031K14608 0 0 16,32,64,512 routetbl 80419K 20K 38031K10554 0 0 16,32,64,128,256 ifaddr7414K 14K 38031K 76 0 0 16,32,64,128,256,512,2048 sysctl 2 1K 1K 38031K2 0 0 16,128 ioctlops 0 0K 4K 38031K10006 0 0 256,512,1024,2048,4096 mount 5 3K 3K 38031K5 0 0 512 NFS node 1 8K 8K 38031K1 0 0 8192 vnodes82 8K 44K 38031K 9323 0 0 16,32,128,256 namecache 325K 25K 38031K3 0 0 1024,8192,16384 UFS quota 1 8K 8K 38031K1 0 0 8192 UFS mount2141K 41K 38031K 21 0 0 16,32,512,2048,4096,8192 shm 2 1K 1K 38031K2 0 0 256,512 VM map 3 1K 1K 38031K3 0 0 256 sem 3 1K 1K 38031K3 0 0 16,32,64 dirhash 10520K 20K 38031K 384 0 0 16,32,64,128,256,512 file desc 1 1K 1K 38031K2 0 0 256 proc19 3K 3K 38031K 19 0 0 32,256,1024 VFS cluster 0 0K 1K 38031K 4963 0 0 32 NFS srvsock 2 1K 1K 38031K2 0 0 256 NFS daemon 1 1K 1K 38031K1 0 0 256 in_multi22 1K 1K 38031K 22 0 0 16,64 ether_multi 4 1K 1K 38031K4
ICP90x4RO - ICP SCSI U320 - PCI-X - OpenBSD
Hi, the new ICP-Vortex ICP90x4RO (ICP SCSI U320 - PCI-X) SCSI-RAID controllers do not seem to be supported by the OpenBSD gdt-module. Are there any workarounds or plans to support the new ICP-Vortex RAID-hardware within the next release? - Flo
uvm_fault
Hi, I have problems with an OpenBSD 3.9 GENERIC.MP#0 i386 machine causing uvm_fault crashes: uvm_fault(0xd05cc640, 0xedbe2000, 0, 3) - e kernel page fault trap, code=0 Stopped at memset+0x33: repe stosl %es:(%edi) The system in question is a Fujitsu Siemens Primergy P200 system with five network cards, four Intel PRO/1000MT (82546GB) [em0-3] and one Intel 8255x [fxp0]. It has an Adaptec 2100S RAID controller and 1.5 GB memory. Real memory usage is usually between Memory: Real: 200M/336M. Any ideas would be great, thanks for your time, - Florian
Re: uvm_fault
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Marcus Popp
On 2007-01-05T13:47, Florian Fuessl wrote:
Hi,
I have problems with an OpenBSD 3.9 GENERIC.MP#0 i386 machine causing
uvm_fault crashes:
[...]
Any ideas would be great, thanks for your time,
please go to http://www.openbsd.org/report.html and read it.
thanks, Marcus.
Hi, thanks for the many reply messages.
Today the machine in question caused one more kernel page fault with the
error message below. I now guess it's a hardware error and not an OpenBSD
bug in this case.
Many thanks for your help,
- Flo
+++ \\\ /// +++
kernel: page fault trap, code=0
Stopped at ip_output+0x7e0:testb $0x5,0x34(%eax)
ddb{0} trace
ip_output(ec846000,0,0,2,d05e5bc8,0,ea436d80,d01e6f0d) at ip_outputx0x7e0
pfsync_sendout_mbuf(d05e5a00,ec846000,ea436db0,d01c3c56,ea436e40) at
pfsync_sen
dout_mbuf+0x106
pfsync_sendout(d05e5a00,ecb1c800,ea436dd0) at pfsync_sendout+0x57
pfsync_request_update(d904284c,ea436e40,8,d90428c) at
pfsync_request_update+0x
3c
pfsync_input(ec1e8800,14,0,0,4b0bbdde) at pfsync_input+0x1006
ipv4_input(ec1e8800,d028e557,8,286) at ipv4_input+0x4f1
ipintr(0,d034,10,10,ea435000) at ipintr+0x67
Bad frame pointer: 0xea436f20
ddb{0}
openbsd 3.9 spamd quits/crashes without any error msg in the logs
Hi, we are using spamd of OpenBSD 3.9 in greylisting mode with the following options in rc.conf: spamd_flags=-v -G 25:4:864 -r451 spamd_grey=YES . and the greyscanner perl script from Bob Beck. The results in fighting against spam are really unbelievable great, but unfortunately spamd crashes or quits from time to time on the system here without any error message in the logfiles and we have to manually restart the service: i.e.: +++ \\\ /var/log/spamd /// +++ Dec 3 22:06:10 o-bgp6 spamd[27825]: 88.83.209.235: connected (788/210) Dec 3 22:06:10 o-bgp6 spamd[27825]: (GREY) 85.99.89.88: [EMAIL PROTECTED] - [EMAIL PROTECTED] Dec 3 22:06:10 o-bgp6 spamd[27825]: 85.99.89.88: disconnected after 13 seconds. Dec 3 22:06:10 o-bgp6 spamd[27825]: 62.73.214.146: connected (788/211), lists: becks Dec 3 22:06:10 o-bgp6 spamd[27825]: 88.226.189.237: connected (789/211) Dec 3 22:06:11 o-bgp6 spamd[27825]: 216.227.18.97: disconnected after 403 seconds. Dec 3 22:06:11 o-bgp6 spamd[27825]: 84.174.120.60: disconnected after 411 seconds. Dec 4 03:40:48 o-bgp6 spamd[22104]: listening for incoming connections. Dec 4 03:40:48 o-bgp6 spamd[22104]: 65.207.158.130: connected (1/0) Dec 4 03:40:48 o-bgp6 spamd[22104]: 87.16.59.131: connected (2/0) +++ /// \\\ +++ Are there any known bugs in the 3.9 OpenBSD release of spamd? Any suggestions are welcome :) - Florian
Re: Quagga and OpenBGP
Quagga is not only a BGP routing software, it's a collection of many routing daemons. The syntax is almost comparable to the Cisco syntax, which makes it possible to let Quagga-routers be maintained by almost everyone who knows to handle Cisco products. Nevertheless the OpenBSD port of Quagga is out of date and has no support for TCP-MD5. So if possible, it's probably a better idea to use the OpenBSD routing daemons on OpenBSD systems as long as no-one seems to actively maintain the Quagga port for OpenBSD... -Flo -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Demuel I. Bendano, R.E.E Sent: Thursday, November 30, 2006 6:41 PM To: misc@openbsd.org Subject: Quagga and OpenBGP All, I cannot still see the logic as to why Quagga is part of the OpenBSD ports tree when it has OpenBGP at all in the default install? The documentation of OpenBGP tells us that it is far superior in design as compared to Zebra/Quagga. Side comments? dems
