Re: offloading layer 7 packet classification to hardware
On Thu, Oct 30, 2008 at 2:39 PM, Eduardo Meyer [EMAIL PROTECTED] wrote: how does pfsense classify p2p traffic? via the ports it typically uses. --Bill
Re: bio not working on dl380 g4 with newer ciss fw
On 4/12/07, Kalle Andersson [EMAIL PROTECTED] wrote: Hello Misc! I have a 2 HP DL380 G4 where the ciss bio stuff behaves differently... Im hoping someone can give me a clue... box1: # bioctl ciss0 Volume Status Size Device ciss0 0 Online 293617820160 sd0 RAID5 0 Online 146811543552 1:0.0 noencl COMPAQ BD14689BB9 1 Online 146811543552 1:1.0 noencl COMPAQ BD14689BB9 2 Online 146811543552 1:2.0 noencl COMPAQ BD14689BB9 3 Hot spare146811543552 1:3.0 noencl COMPAQ BD14689BB9 box2: # bioctl ciss0 bioctl: Can't locate ciss0 device via /dev/bio Only difference I can see that might have something to do with it is: box1: ciss0: 1 LD, HW rev 1, FW 2.58/2.58 box2: ciss0: 2 LDs, HW rev 1, FW 2.68/2.68 Is box2's bio not working because the 2.68 FW or that it has two logical drives? Is FW 2.68 going to be supported or should I try to downgrade (if that even is possible)? Two logical drives. Not sure about the firmware version, but the more than one logical drive issue is in the caveats section of ciss(4). --Bill
Re: 802.11g in ath(4) driver
On 3/7/07, Jonathan Gray [EMAIL PROTECTED] wrote: On Tue, Mar 06, 2007 at 11:55:10PM -0600, Bill Marquette wrote: Any reason ath(4) only currently supports 11b mode? Looks like it was commented out in the driver in September with the comment for now. Just wondering if we're going to see it back for 4.1, or what's broken with it that it was removed. --Bill The voodoo required to initialise the cards for 11g rates has not been fully worked out yet. Atheros publishes no datasheets on any of their products and are openly hostile to people trying to understand how to interface to them. Thanks for the explanation. Is there anything I can do to help? Testing patches, sending hardware, prodding Atheros? What's the best supported 11g driver these days, is it ral(4)? --Bill
802.11g in ath(4) driver
Any reason ath(4) only currently supports 11b mode? Looks like it was commented out in the driver in September with the comment for now. Just wondering if we're going to see it back for 4.1, or what's broken with it that it was removed. --Bill
pf state limits
I know this has come up in the past but I haven't been able to track down a definitive answer (I'm sure there's a reason why), so I'll ask the question again. Given a i386 kernel, assume I can toss as much RAM at the box as needed (I know this isn't the limitation, it's a kernel memory issue), what's the maximum I can set the state table size to? I have a couple boxes that are running around 200K states with the limit set at 256K. I expect that I will see a growth in that state table size as the traffic to the servers behind these machines increases during our peak season. I can tune the tcp.closed parameter a bit on the external rules as 75% of these states are fin_wait_2:fin_wait_2, but before I start messing with that I'd rather increase the state limit some more. I can also try adaptive timeouts on those rules, but I'm more than a little paranoid about having the system dynamically change timeout values. Any suggestions on what the max might be and how I can monitor the system to see where I'm at in relationship to the max (if there's no hard number, I'm guessing the number depends on hardware and other system options that affect kernel memory). --Bill
Re: Slow write performance on Compaq Smart Array 64xx (ciss0)
On 1/28/07, Henning Brauer [EMAIL PROTECTED] wrote: * Vijay Sankar [EMAIL PROTECTED] [2007-01-28 16:07]: bioctl -h ciss0 gives me bioctl: Can't locate ciss0 device via /dev/bio ciss doesn't support bio yet. Unless I'm mistaken, mickey@ added it pre-4.0 here: http://marc.theaimsgroup.com/?l=openbsd-cvsm=115671197617717w=2 and bio(4) man page claims it's supported as does ciss(4) (albeit with a caveat) --Bill
Re: Quagga and OpenBGP
On 11/30/06, Demuel I. Bendano, R.E.E [EMAIL PROTECTED] wrote: 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? BGP isn't the only reason you might use Quagga. I use it for RIP since routed doesn't have any method of enforcing what networks are learned from what gateways. I've got a couple machines that need to send me a limited number of routes, I know exactly what those routes are, but not which of the gateways will send it and have never figured out a way to restrict that in the routed config. I haven't looked at openripd (or whatever the new RIP daemon is called) yet, but plan on it before our next upgrade to see if I can ditch Quagga. --Bill
kern.nprocs not (closely) matching ps -ax |wc -l ??
I understand that the ps -ax would have spawned at least one more process (and a header) than the sysctl count, but I'm not seeing why sysctl is showing 11 more processes than ps does: $ sysctl kern.nprocs (ps -ax |wc -l) sysctl kern.nprocs kern.nprocs=46 35 kern.nprocs=46 This machine has been up a while and has had enough various errors to make the boot dmesg disappear from logs, so here's the various kern.* sysctl's that show what kernel I'm running: kern.ostype=OpenBSD kern.osrelease=3.8 kern.osrevision=200511 kern.version=OpenBSD 3.8-current (GENERIC) #320: Sat Dec 17 10:09:10 MST 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC A 3.9 system is a tad different, but exhibits the same strangeness: $ sysctl kern.nprocs (ps -ax |wc -l) sysctl kern.nprocs kern.nprocs=48 39 kern.nprocs=48 Any idea where the discrepancy might be coming from? --Bill
Re: kern.nprocs not (closely) matching ps -ax |wc -l ??
On 10/30/06, Otto Moerbeek [EMAIL PROTECTED] wrote: On Mon, 30 Oct 2006, Bill Marquette wrote: I understand that the ps -ax would have spawned at least one more process (and a header) than the sysctl count, but I'm not seeing why sysctl is showing 11 more processes than ps does: $ sysctl kern.nprocs (ps -ax |wc -l) sysctl kern.nprocs kern.nprocs=46 35 kern.nprocs=46 This machine has been up a while and has had enough various errors to make the boot dmesg disappear from logs, so here's the various kern.* sysctl's that show what kernel I'm running: kern.ostype=OpenBSD kern.osrelease=3.8 kern.osrevision=200511 kern.version=OpenBSD 3.8-current (GENERIC) #320: Sat Dec 17 10:09:10 MST 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC A 3.9 system is a tad different, but exhibits the same strangeness: $ sysctl kern.nprocs (ps -ax |wc -l) sysctl kern.nprocs kern.nprocs=48 39 kern.nprocs=48 Any idea where the discrepancy might be coming from? By default, ps does not show kernel processes. See ps(1), -k option. -Otto Gah, thanks! Never occurred to me that -a wouldn't show all processes. Learn something every day, thanks to all for their responses. --Bill --Bill
Re: pf load balancing and failover
On 10/22/06, Per-Olov Sjvholm [EMAIL PROTECTED] wrote: Hi I have followed this thread. Can anyone point out a working download link? Sourceforge does not have any working mirrors for this slbd-1.3.tar.gz file.. Probably a misconfiguration somewhere. Hmm, didn't notice that they didn't mirror it properly when I posted it last night. You can try pulling it down from CVS @ http://sourceforge.net/cvs/?group_id=96331 I'll see what I can do to whip sourceforge into shape and get the mirroring fixed. Thanks --Bill
Re: pf load balancing and failover
On 10/21/06, Kevin Reay [EMAIL PROTECTED] wrote: there should be a userland process doing these checks and reoving the offending address from the pool on failure. unfortunately, to my knowledge, still nobody wrote something which does it. A while ago I used this with great success: http://slbd.sourceforge.net/ It's open source (bsd!) and written for OpenBSD and pf. Unfortunately it seems to have become outdated (won't compile on recent versions of OpenBSD) because of the changed pf interface. (updating it probably wouldn't be too much work) It had the ability to query webservers (http), ping ip addresses, and connect Point of correction, slbd didn't have the ability to ping IP addresses. to specific tcp ports for heartbeat; and it would automatically remove the address from a pf poll (and optionality run a command) when a host failed. It really would be cool if someone updated it (maybe me if I get some time in the future) You might check the code in CVS, it should compile and work on 3.9. --Bill
ath0: device timeout errors
Obviously these aren't GENERIC kernels; I don't have a way to get it on these machines, so ignore away, but hopefully this is of some use. All tests were using 11b mode since 11g is disabled in the current ath(4) driver (and I started in -current) and mediaopt hostap (although I believe I tested in infrastructure mode also w/ no better results). Wistron CM9, works on Aug 4th checkout (I assume djm checked out w/in a day of the kernel being built) OpenBSD 4.0-beta (WRAP12) #0: Fri Aug 4 10:27:21 EST 2006 [EMAIL PROTECTED]:/home/djm/code/flashboot/obj/WRAP12 ... ath0 at pci0 dev 13 function 0 Atheros AR5212 rev 0x01: irq 12 ath0: AR5213 5.9 phy 4.3 rf5112a 3.6, FCC2A*, address 00:0b:6b:4d:58:10 Doesn't work with Sept 23rd checkout. OpenBSD 4.0-current (WRAP12) #0: Sat Sep 23 18:46:39 CDT 2006 [EMAIL PROTECTED]:/home/billm/flashboot/obj/WRAP12 ... ath0 at pci0 dev 13 function 0 Atheros AR5212 rev 0x01: irq 12 ath0: AR5213 5.9 phy 4.3 rf5112a 3.6, FCC2A*, address 00:0b:6b:4d:58:10 The exact opposite is true of the IBM card I have ath0 at pci0 dev 14 function 0 Atheros AR5212 (IBM MiniPCI) rev 0x01: irq 11 ath0: AR5213 5.6 phy 4.1 rf5111 1.7 rf2111 2.3, WOR1W, address 00:05:4e:43:35:82 This one works with the code from Sept 23, but gives device timeout errors with the earlier code. One possibly important point of difference between the two cards is that on the Wistron I have both antenna's connected, while on the IBM, I only have the main antenna connected. --Bill
Re: anyone have a recipe for shaping torrent traffic with pf + snort ?
On 9/8/06, Andrew Atrens [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Folks, Looking for a simple way to tag bittorent connections based on packet content so that I can shape them with pf/altq... Heard it can be done with a combination of pf and snort .. googled some old references to a now-defunct freshmeat project called 'snortpf'. Anyone have a recipe or outline for how this might be done ? I've found it easier to classify good traffic based on ports and then make the p2p queues the default queues so that anything that isn't matched gets lower priority. --Bill
Re: Raid controller compatibility.
On 9/8/06, Kaven Gagnon (ml) [EMAIL PROTECTED] wrote: Hi, I would like to know if these three SCSI controllers are compatible with OpenBSD? (No mention about these cards on the manifacturer Web site and OpenBSD compatibility list.) All of these cards are listed on the i386 hardware page. http://www.openbsd.org/i386.html Adaptec SCSI RAID 2000S Adaptec SCSI RAID 2010S I2O adapters (iop), including: (A) (C) * Adaptec SCSI RAID (ASR-2100S, ASR-2110S, ASR-3200S, etc.) MegaRAID SCSI 320-0 (520-0 CH) American Megatrends Inc. MegaRAID controllers in Mass Storage mode (ami), including: (A) (C) * LSI/AMI MegaRAID, MegaRAID 320-0, MegaRAID 320-1, MegaRAID 320-2, MegaRAID 320-1E, MegaRAID 320-2E, --Bill
Re: network cards - which one is the best ;
On 9/4/06, Matthew R. Dempsky [EMAIL PROTECTED] wrote: On Mon, Sep 04, 2006 at 09:30:13AM +, Marcus Popp wrote: On 2006-09-03T23:16, Bill Marquette wrote: Other than Intel, is anyone else making quad port gig cards? Silicom makes em-based quad/six port cards. I thought the point of this subthread was Bill trying to avoid em(4)-based cards? More or less :) I can certainly continue to live with em(4), but I'm definitely seeing some bottlenecks (interrupt load) with it on my hardware (HP DL380 G4's - I have some new DL385's in that I haven't benchmarked) w/ i386 non-MP kernel (MP kernel in my testing seemed to negatively impact throughput performance even in MP hardware). One important note is that this is with the previous generation of the pci-x boards, I haven't retested with the currently shipping boards that are only supported in 4.0. --Bill
Re: network cards - which one is the best ;
On 9/3/06, Ted Unangst [EMAIL PROTECTED] wrote: On 9/3/06, Sylwester S. Biernacki [EMAIL PROTECTED] wrote: I use Intel cards for several years and was happy of them almost all the time. However, after I've read about them at this list usenet for the last few months I had to stand up and throw away all of them. Theo wrote about em driver in OpenBSD and bad vendor design of Intel NICs in general. Exactly the opposite I have used Intel server cards with ~320Mbps traffic (max of old PCI board ;P) and everything worked as it should. if they work great for you, why do you care? Other than Intel, is anyone else making quad port gig cards? I'm always open to playing with other hardware (and am hitting some amount of limitations with my current hardware setup anyway) but haven't run across any decent quad cards lately. --Bill
Re: service monitoring and pf load balancing
On 8/3/06, Siju George [EMAIL PROTECTED] wrote: On 8/3/06, Bill Marquette [EMAIL PROTECTED] wrote: slbd - http://slbd.sourceforge.net/ might be what you're looking for. The CVS code has numerous fixes that aren't in the 1.2 release. Disclaimer: I'm the current maintainer (but not the author) of that code. This is great Bill :-) Does it work well on 3.9? I haven't specifically tested it on 3.9 at this time (soon as I have some need for it). I find x86-based system running OpenBSD 3.3 or 3.4 (others may work, but I haven't tested with anything else; OpenBSD 3.5 support is forthcoming) on the site :-( is that outdated info? Very. I haven't updated the site since taking over the maintainer role. The code in CVS should compile and run on 3.9 cleanly - as soon as I've tested it myself I was planning on rolling out a 1.3 release (and I suppose I should check for it's status in ports and update ;)). --Bill
Re: service monitoring and pf load balancing
On 8/2/06, ben [EMAIL PROTECTED] wrote: I'm using a pf to round-robin redirect incoming requests (in this case http) to a pf address pool. I'm using pf to perform redirection in this situation instead of using a proxy specifically to avoid the source addresses in the log files as being that of the proxy server. I'm aware of tools that process logs from the proxy and from apache and produce rewritten apache logs with the correct IPs, but for various reasons it wouldn't be an acceptable solution. I need a way to monitor the boxen in the address pool for availablity and rewrite the pf rules accordingly. In other words, if a box or it's services die it needs to be removed from the pool. I'm trying to go for as simple and as generic a solution as possible. And I intend to use it in the future with other services, not just http. CARP comes very close to solving the problem, but it's not specific to individual tcp ports afaik. So it would help if a box becomes completely unreachable, but if only the service stops working it's not that useful. Essentially I'm looking for a very simple daemon that can monitor services on several machines and trigger pfctl when the availablity of the services changes. It's been suggested to me that the Linux-HA/heartbeat package may have what I'm looking for, but from what I can tell it's never successfully run on OpenBSD. Any thoughts, suggestions or pointers would be very appreciated. slbd - http://slbd.sourceforge.net/ might be what you're looking for. The CVS code has numerous fixes that aren't in the 1.2 release. Disclaimer: I'm the current maintainer (but not the author) of that code. --Bill
Re: Spurious No route to host indications on multiple releases?
On 7/11/06, Stuart Henderson [EMAIL PROTECTED] wrote: On 2006/07/11 10:46, Michael Durket wrote: Yes - I am using 'pf' with keep state. I'm not sure what you'd define as high-rate. Our mail servers process hundreds of messages a minute, but I doubt that would qualify as high-rate (compared to what some other mail sites get). Our other OpenBSD systems that got the No route to host messages were not processing high-rate connections ( 10 connections per minute) but did run pf with keep state. No route to host when there is a route entry is generally indicating packets are blocked by PF.. try `pfctl -x misc' and take a look at syslog. Moved to misc@openbsd.org, this is not a tech@ topic and more people who may have input might see it there. Try setting tcp.closed lower for the rule in question. It's default is 90 seconds, which in some cases appears to be a little high (although I believe there is a good reason for it, I just can't find it). --Bill
SAS controllers?
Are any SAS controllers (LSI, or otherwise) supported? The HP DL380 G5's are supposed to start shipping with the P600 controller - looking at the ciss(4) driver, I _think_ it works, but I'm not sure I'm reading correctly ;) --Bill
Re: PCI-X not seen by 3.8 on HP DL-145 G2
On 1/13/06, Bill Marquette [EMAIL PROTECTED] wrote: On 1/11/06, Bill Marquette [EMAIL PROTECTED] wrote: On 12/9/05, Srebrenko Sehic [EMAIL PROTECTED] wrote: The ciss driver works fine (no idea about speeds at this time, more on that in a second). The onboard broadcom nics do show up, but I can't seem to get link on them pci-x connected cards are mia even though the pci-x bus looks like it's configured (I believe on the uniprocessor kernel it didn't configure it, I can recheck that). With no network, it was kind of difficult to get anything on the system for IO tests on the disks, which wasn't a huge deal for me in the first place. I wanted to followup on the network connectivity issue I mentioned with the DL385. I obviously didn't try hard enough. After moving the machine to another location and using a crossover cable to connect it to another OpenBSD box instead of a switch, I'm seeing link activity and can get online with it. The PCI-X issues are still there, but for those that don't care about that, the machine does work with onboard disk and onboard network. With the 2/12/06 amd64 snapshot all of the PCI busses are now showing on the HP DL385 G4's. One small issue with the LSI MegaRAID card I have in one of the slots, but I haven't spent any time looking into it (ie. it's probably operator error). ami0 at pci5 dev 8 function 0 Symbios Logic MegaRAID rev 0x01: can't map controller pci space dmesg from install CD - I'll spend more time doing an install later. Thanks a ton to the developers that worked on this and made it happen in time for 3.9! --Bill OpenBSD 3.9-beta (RAMDISK_CD) #657: Sun Feb 12 22:17:40 MST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 1073311744 (1048156K) avail mem = 909639680 (888320K) using 22937 buffers containing 107540480 bytes (105020K) of memory mainbus0 (root) cpu0 at mainbus0: (uniprocessor) cpu0: AMD Opteron(tm) Processor 275, 2205.29 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,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative pci0 at mainbus0 bus 0: configuration mode 1 ppb0 at pci0 dev 3 function 0 AMD 8111 PCI-PCI rev 0x07 pci1 at ppb0 bus 1 ohci0 at pci1 dev 0 function 0 AMD 8111 USB rev 0x0b: irq 7, version 1.0, legacy support usb0 at ohci0: USB revision 1.0 uhub0 at usb0 uhub0: AMD OHCI root hub, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1 at pci1 dev 0 function 1 AMD 8111 USB rev 0x0b: irq 7, version 1.0, legacy support usb1 at ohci1: USB revision 1.0 uhub1 at usb1 uhub1: AMD OHCI root hub, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered Compaq iLO rev 0x01 at pci1 dev 2 function 0 not configured Compaq iLO rev 0x01 at pci1 dev 2 function 2 not configured vga1 at pci1 dev 3 function 0 ATI Rage XL rev 0x27 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) AMD AMD8111 LPC rev 0x05 at pci0 dev 4 function 0 not configured pciide0 at pci0 dev 4 function 1 AMD 8111 IDE rev 0x03: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility atapiscsi0 at pciide0 channel 0 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: TEAC, CD-224E, 9.9A SCSI0 5/cdrom removable cd0(pciide0:0:0): using PIO mode 4, DMA mode 2 pciide0: channel 1 ignored (disabled) AMD 8111 Power rev 0x05 at pci0 dev 4 function 3 not configured ppb1 at pci0 dev 7 function 0 AMD 8131 PCIX rev 0x12 pci2 at ppb1 bus 2 ciss0 at pci2 dev 4 function 0 Compaq Smart Array 64xx rev 0x01: irq 7 ciss0: 1 LD, HW rev 1, FW 2.58/2.58 scsibus1 at ciss0: 1 targets sd0 at scsibus1 targ 0 lun 0: HP, LOGICAL VOLUME, 2.58 SCSI0 0/direct fixed sd0: 34727MB, 34727 cyl, 64 head, 32 sec, 512 bytes/sec, 71122560 sec total AMD 8131 PCIX IOAPIC rev 0x01 at pci0 dev 7 function 1 not configured ppb2 at pci0 dev 8 function 0 AMD 8131 PCIX rev 0x12 pci3 at ppb2 bus 3 bge0 at pci3 dev 6 function 0 Broadcom BCM5704C rev 0x10, BCM5704 B0 (0x2100): irq 7, address 00:15:60:ab:d2:8c brgphy0 at bge0 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 bge1 at pci3 dev 6 function 1 Broadcom BCM5704C rev 0x10, BCM5704 B0 (0x2100): irq 7, address 00:15:60:ab:d2:8b brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 AMD 8131 PCIX IOAPIC rev 0x01 at pci0 dev 8 function 1 not configured pchb0 at pci0 dev 24 function 0 AMD AMD64 HyperTransport rev 0x00 pci4 at pchb0 bus 4 ppb3 at pci4 dev 9 function 0 AMD 8131 PCIX rev 0x12 pci5 at ppb3 bus 5 ppb4 at pci5 dev 7 function 0 IBM PCIX-PCIX rev 0x02 pci6 at ppb4 bus 6 em0 at pci6 dev 4 function 0 Intel PRO/1000MT QP (82546EB) rev 0x01: irq 7, address 00:04:23:c6:96:4c em1 at pci6 dev 4 function 1 Intel PRO/1000MT QP (82546EB) rev 0x01
Re: OpenBSD/i386 3.8 on a Compaq DL380 SMP with GENERIC.MP
On 1/30/06, Bruno Carnazzi [EMAIL PROTECTED] wrote: Hi all, Everything seems to work fine but OpenBSD find only one CPU ! :( Somebody know why and how can I use the 2 CPUs ? Thank you, Bruno. Here is the dmesg : SNIP DMESG Works fine here on the DL380G4's with -current (worked with release too if I remember correctly). From your dmesg, this looks like a first generation box - there's numerous tweaks in the BIOS on these machines. Until recently I also had a DL360G1 running 3.7 with both CPUs recognized - this should be more or less the same hardware you have. --Bill dmesg from DL380G4: OpenBSD 3.9-beta (GENERIC.MP) #1: Sat Jan 21 13:54:56 CST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2147033088 (2096712K) avail mem = 1835864064 (1792836K) using 22937 buffers containing 214913024 bytes (209876K) of memory mainbus0 (root) mainbus0: Intel MP Specification (Version 1.4) (HP PROLIANT) cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(TM) CPU 3.40GHz, 3400.56 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,SBF,SSE3,NXE,LONG cpu0: 1MB 64b/line 8-way L2 cache cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 6 (application processor) cpu1: Intel(R) Xeon(TM) CPU 3.40GHz, 3400.13 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,SBF,SSE3,NXE,LONG cpu1: 1MB 64b/line 8-way L2 cache mpbios: bus 0 is type PCI mpbios: bus 1 is type PCI mpbios: bus 2 is type PCI mpbios: bus 3 is type PCI mpbios: bus 4 is type PCI mpbios: bus 5 is type PCI mpbios: bus 6 is type PCI mpbios: bus 10 is type PCI mpbios: bus 32 is type ISA ioapic0 at mainbus0 apid 8: pa 0x83741f24, version 20, 24 pins ioapic1 at mainbus0 apid 9: pa 0x83741e24, version 20, 24 pins ioapic2 at mainbus0 apid 10: pa 0x83741d24, version 20, 24 pins ioapic3 at mainbus0 apid 11: pa 0x83741c24, version 20, 24 pins ioapic4 at mainbus0 apid 12: pa 0x83741b24, version 20, 24 pins pci0 at mainbus0 bus 0: configuration mode 1 pchb0 at pci0 dev 0 function 0 Intel E7520 MCH rev 0x0a ppb0 at pci0 dev 2 function 0 Intel MCH PCIE rev 0x0a 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): apic 9 int 1 (irq 7), address 00:0f:20:f7:65:89 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): apic 9 int 2 (irq 7), address 00:0f:20:f7:65:88 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 ppb3 at pci0 dev 6 function 0 Intel MCH PCIE rev 0x0a pci4 at ppb3 bus 5 ppb4 at pci4 dev 0 function 0 Intel PCIE-PCIE rev 0x09 pci5 at ppb4 bus 6 ami0 at pci5 dev 2 function 0 Symbios Logic MegaRAID rev 0x01: apic 11 int 6 (irq 7) LSI 520 64b/lhc ami0: FW 1L19, BIOS v1.04, 64MB RAM ami0: 1 channels, 0 FC loops, 1 logical drives scsibus0 at ami0: 40 targets sd0 at scsibus0 targ 0 lun 0: AMI, Host drive #00, SCSI2 0/direct fixed sd0: 34731MB, 34731 cyl, 64 head, 32 sec, 512 bytes/sec, 71129088 sec total scsibus1 at ami0: 16 targets ppb5 at pci4 dev 0 function 2 Intel PCIE-PCIE rev 0x09 pci6 at ppb5 bus 10 ppb6 at pci6 dev 1 function 0 IBM PCIX-PCIX rev 0x02 pci7 at ppb6 bus 11 em0 at pci7 dev 4 function 0 Intel PRO/1000MT QP (82546EB) rev 0x01: apic 8 int 7 (irq 7), address 00:04:23:b2:ab:48 em1 at pci7 dev 4 function 1 Intel PRO/1000MT QP (82546EB) rev 0x01: apic 8 int 7 (irq 7), address 00:04:23:b2:ab:49 em2 at pci7 dev 6 function 0 Intel PRO/1000MT QP (82546EB) rev 0x01: apic 8 int 7 (irq 7), address 00:04:23:b2:ab:4a em3 at pci7 dev 6 function 1 Intel PRO/1000MT QP (82546EB) rev 0x01: apic 8 int 7 (irq 7), address 00:04:23:b2:ab:4b ppb7 at pci0 dev 30 function 0 Intel 82801BA AGP rev 0xc2 pci8 at ppb7 bus 1 vga1 at pci8 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 pci8 dev 4 function 0 not configured Compaq iLO rev 0x01 at pci8 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 scsibus2 at atapiscsi0: 2 targets cd0 at scsibus2 targ 0 lun 0: TEAC, DW-224E-B, C.6F SCSI0 5/cdrom removable cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 disabled (no drives) 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:
Re: AMD64 Hardware.
On 1/12/06, RV Tec [EMAIL PROTECTED] wrote: SNIP Also, on a related issue: any thoughts on SUN FIRE X4200? I recently got my hands on one, there's some issues with it (like the SAS drives aren't showing up, oops). If the usb on it works, I'll post a dmesg from this hardware next week. From memory, it has the same pci-x bus issue as the dl385 I posted about earlier, the onboard Intel cards did come up, the onboard LSI controller may have been recognized (not sure), but it's attached storage was not. --Bill
Re: PCI-X not seen by 3.8 on HP DL-145 G2
On 1/13/06, Bill Marquette [EMAIL PROTECTED] wrote:
I wanted to followup on the network connectivity issue I mentioned
with the DL385. I obviously didn't try hard enough. After moving the
machine to another location and using a crossover cable to connect it
to another OpenBSD box instead of a switch, I'm seeing link activity
and can get online with it.
The PCI-X issues are still there, but for those that don't care about
that, the machine does work with onboard disk and onboard network.
My definition of work btw is it works and I was able to get a cvs
update completed. However a simple SCP to a machine direct connected
to it b0rks it - each panic is different (joy). The latest from a cvs
update earlier this evening is:
# scp /bsd /bsd /bsd 192.168.177.2:/
The authenticity of host '192.168.177.2 (192.168.177.2)' can't be established.
RSA key fingerprint is cd:bd:f7:e9:c6:85:5c:e1:17:6f:a6:6c:3f:9b:ad:98.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.177.2' (RSA) to the list of known hosts.
[EMAIL PROTECTED]'s password:
bsd 0%0 0.0KB/s
--:-- ETAkernel: machine check trap, code=0
Stopped at microuptime+0x3f: leave
ddb{0} trace
microuptime() at microuptime+0x3f
mi_switch() at mi_switch+0xa2
preempt() at preempt+0xb2
trap() at trap+0x556
--- trap (number 3) ---
end of kernel
end trace frame: 0x4000, count: -4
0x41d5331a:
ddb{0}
This is running amd64 GENERIC.MP with one (hopefully) minor change
setting CONADDR to 0x2f8 so I can use the Compaq iLO from remote to
have serial console access (via ssh, neat!) - as the iLO sits on BIOS
com2 (boot loader com1). I can panic it with the same command w/a
generic kernel too, just can't get the backtrace :)
show all procs shows
ddb{0} [All procs
PID PPID PGRPUID S FLAGS WAIT COMMAND
5263 28221 28221 0 2 0x2004086 ssh
*28221 25756 28221 0 2 0x4006 scp
25756 1 25756 0 3 0x2004086 pause ksh
32639 1 1 0 3 0x2004084 ttyopn getty
32710 1 32710 0 3 0x2004086 ttyin getty
22120 1 22120 0 3 0x2004086 ttyin getty
5890 1 5890 0 3 0x2004086 ttyin getty
1667 1 1667 0 3 0x2004086 ttyin getty
21591 1 21591 0 3 0x2004086 ttyin getty
20141 1 20141 0 3 0x284 select cron
13916 1 13916 0 3 0x2040184 select sendmail
17527 1 17527 0 3 0x284 select sshd
27479 1 27479 0 3 0x2000184 select inetd
29091 24809 24809 73 3 0x2000184 poll syslogd
24809 1 24809 0 3 0x284 netio syslogd
11 0 0 0 3 0x2100204 crypto_wa crypto
10 0 0 0 3 0x2100204 aiodoned aiodoned
9 0 0 0 3 0x2100204 syncer update
8 0 0 0 3 0x2100204 cleanercleaner
7 0 0 0 30x100204 reaper reaper
6 0 0 0 3 0x2100204 pgdaemon pagedaemon
5 0 0 0 3 0x2100204 pftm pfpurge
4 0 0 0 3 0x2100204 usbevt usb1
3 0 0 0 3 0x2100204 usbtsk usbtask
2 0 0 0 3 0x2100204 usbevt usb0
1 0 1 0 3 0x2004084 wait init
0 -1 0 0 3 0x2080204 scheduler swapper
Until (and even after for some time) one of these shows up in a
developers hands (already volunteered), I can provide serial console
access and full lights out management access to this box (and to the
box that I'm scp'ing too).
dmesg from various kernels...
AMD64 SMP kernel from 1/7/06
http://www.pfsense.com/~billm/dmesg.amd64.mp.txt
AMD64 non-SMP kernel from 1/7/06
http://www.pfsense.com/~billm/dmesg.amd64.uni.txt
i386 non-SMP kernel from 1/7/06 (bsd.rd from snapshot cd)
http://www.pfsense.com/~billm/dmesg.i386.uni.txt
AMD64 SMP kernel w/ console set to com1 from 1/13/06
http://www.pfsense.com/~billm/dmesg.amd64.mp.com1.txt
--Bill
Re: PCI-X not seen by 3.8 on HP DL-145 G2
On 12/9/05, Srebrenko Sehic [EMAIL PROTECTED] wrote: 5) DL385, SCSI/RAID/SmartArray P600/6i/6400 = showstopper, OpenBSD can't see the raiser board and hence the RAID controller seated in it (tested on amd64/3.8-STABLE and -current) I can confirm this is still the case on a snapshot from a couple days ago. dmesg sent in to dmesg@, I'd be willing to provide dmesg's for i386 uni and mp kernels as well as amd64 uni and mp (already sent in the mp). The ciss driver works fine (no idea about speeds at this time, more on that in a second). The onboard broadcom nics do show up, but I can't seem to get link on them pci-x connected cards are mia even though the pci-x bus looks like it's configured (I believe on the uniprocessor kernel it didn't configure it, I can recheck that). With no network, it was kind of difficult to get anything on the system for IO tests on the disks, which wasn't a huge deal for me in the first place. I might be able to provide one of these machines (like the whole machine, not just access to it) to a developer interested in making it work. Contact me off-list if there's any interest and I'll see what I can do. --Bill
Re: HP DL 380 G3 + OpenBSD 3.8
On 10/26/05, lEBEDEW aNDREJ gERMANOWI^ [EMAIL PROTECTED] wrote: My problem (!!!) - bge1 at pci4 dev 2 function 0 Broadcom BCM5703X rev 0x02: couldn't establish interrupt at irq 15. Howto ? RTFM ? Help me! In the Compaq BIOS, make sure nothing is configured for IRQ 15. It's an annoying issue I've seen with the DL380's - none of my boxes can have _anything_ configured for IRQ15. The G4's make the choice easier, they only allow 5 and 7 if I recall ;) --Bill
Re: em/carp switches slower than fxp/carp
On 9/26/05, Stephan A. Rickauer [EMAIL PROTECTED] wrote: Bill Marquette wrote: Any chance the em's are on a switch doing spanning tree? Or that the fxp port (on the master is set to port fast)? Sounds like STP locking out the em ports on the master to me. Hit. Each firewall's em interface is connected to one switch per machine with two separate VLAN's. The switches are interconnected by a 'trunk'. I guess the general problem here is two machines appear with one mac address at the same time on both switches, right? How can one solve that? The problem is that the switch will hold down the port to learn what traffic is coming out of it to ensure that you don't introduce a loop. Either turning STP off on the port or changing the port to STP port fast should eliminate the delay, leaving you of course with the risk that someone will plug a switch into those ports and somehow create a loop :) --Bill
Re: em/carp switches slower than fxp/carp
Any chance the em's are on a switch doing spanning tree? Or that the fxp port (on the master is set to port fast)? Sounds like STP locking out the em ports on the master to me. --Bill On 9/23/05, Stephan A. Rickauer [EMAIL PROTECTED] wrote: Hello, is there any known problem related to em interfaces and carp? They take 25 seconds longer to switch status from master to backup compared to an fxp one ... Output of 'while true; do date; ifconfig| grep carp:; sleep 1;done' while rebooting the master (=advskew 50): Fri Sep 23 14:25:16 CEST 2005 carp: MASTER carpdev em0 vhid 1 advbase 1 advskew 100 carp: MASTER carpdev em1 vhid 2 advbase 1 advskew 100 carp: MASTER carpdev fxp0 vhid 3 advbase 1 advskew 100 Fri Sep 23 14:25:17 CEST 2005 carp: MASTER carpdev em0 vhid 1 advbase 1 advskew 100 carp: MASTER carpdev em1 vhid 2 advbase 1 advskew 100 carp: BACKUP carpdev fxp0 vhid 3 advbase 1 advskew 100 . . . Fri Sep 23 14:25:43 CEST 2005 carp: MASTER carpdev em0 vhid 1 advbase 1 advskew 100 carp: MASTER carpdev em1 vhid 2 advbase 1 advskew 100 carp: BACKUP carpdev fxp0 vhid 3 advbase 1 advskew 100 Fri Sep 23 14:25:44 CEST 2005 carp: BACKUP carpdev em0 vhid 1 advbase 1 advskew 100 carp: BACKUP carpdev em1 vhid 2 advbase 1 advskew 100 carp: BACKUP carpdev fxp0 vhid 3 advbase 1 advskew 100 Any ideas? Thanks! -- Stephan A. Rickauer Institut f|r Neuroinformatik Universitdt / ETH Z|rich Winterthurerstriasse 190 CH-8057 Z|rich Tel: +41 44 635 30 50 Sek: +41 44 635 30 52 Fax: +41 44 635 30 53 http://www.ini.ethz.ch
Re: Gigabit Firewall NIC Interrupt Performance Problem
On 6/2/05, Sean Knox [EMAIL PROTECTED] wrote: Hey Bob, Thanks for the info. I originally asked as I'm seeing between 80 and 90 percent interrupts on a gigabit firewall with some em(4) cards. I think my issue may be expected given the scenario, so I'll pose that question to the group in a different thread. thanks, sk I saw a pretty significant performance boost on some of my IDS boxen by putting the NICs on the same IRQ. There was also a tuning article written quite some time ago (no idea about it's current day relevance) that suggested the same. The IDS boxen have em(4) cards in them. Interrupt load dropped tremendously and we gained back a lot of dropped packets :) I had played around with recv timers and buffers and was able to get a 10% performance improvement before changing the cards to the same interrupt; I've since reverted those tunables as I don't see a difference anymore. --Bill
