Re: blade servers
On Feb 7, 2008 8:40 AM, Joe [EMAIL PROTECTED] wrote: On Feb 6, 2008, at 5:45 PM, Need Coffee wrote: Does anyone run OpenBSD on blade servers? I don't mean Sun Blade 150 kind of hardware, but rather blade chassis with server blades (a la Sun Blade 8000, HP, Dell, etc.). I'd appreciate any details... I'm having a bit of trouble finding anything conclusive about OpenBSD on blades. Works fine on FUJITSU SIEMENS PRIMERGY BX630. Have a look at http://www.armorlogic.com/openbsd_information_server_compatibility_list.html?action=detailid=BX630
Re: nfe0 issues
On Nov 6, 2007 2:08 PM, Chris Harper [EMAIL PROTECTED] wrote: I recently installed 4.2 release on my evga 680i based motherboard , which uses nfe(4) for the onboard gig NIC's. There seems to be an issue in the handling of the autodetection of media types and the speed it can run at when manual selection is set. So say for instance I set it manually to 100baseTX it will no longer function and does not send packets. If I then set it to 10baseT it will work fine, I have checked the network routers/cables and interfaces from a windows partition which detects a 100mbps link. I have notived that on the router it detects a 100mbps link before the kernel initiatesthe device during boot i.e before any mention of nfe on the screen. Try using a gigabit switch. I remember having similar issues with which were solved by switching to 1000baseTX.
Re: IDE or SCSI virtual disks for VMWare image?
On 7/6/07, Todd Pytel [EMAIL PROTECTED] wrote: I'm going to be running a few OpenBSD virtual machines and was wondering whether there was any performance difference between using IDE or SCSI virtual disks. From what I can tell, the SCSI option has been supported longer, though IDE has also been stable for a while now. But I haven't seen any comments on performance differences, if any exist. If it matters, this is going to be lightweight, home server kind of stuff. Both work just fine. I myself, always run SCSI via mpi(4). Works like a charm and performs quite well.
Re: how to set PATH in xterm
On 7/2/07, David Burau [EMAIL PROTECTED] wrote: Hi, I'm shure it's just a very small problem, but i can't figure out, what to do. Im runnig OpenBSD 4.0 and i don't know how to set the PATH in xterm. I want to set it to $HOME/bin. The Shell is ksh. In the console it works, but not in xterm. Just start xterm with -ls. It will read you .profile and set the PATH correctly.
Re: nfe0 problem (obsd 4.1)
On 6/24/07, patrick keshishian [EMAIL PROTECTED] wrote: Hi, I've been noticing some strange problems with the built-in nfe0 interface on my desktop. Actually I've seen it on two such computers, but the description below is for my current desktop PC. The PC is running `cvs up -dP -rOPENBSD_4_1' built. I'm including netstat, ifconfig output[1] and dmesg below[2]. I've noticed that once in a while the nfe0 interface will stop sending and receiving data. At this point I can not make it work again. The only solution I have is to reboot the box. I have installed a dc0 card in the box since. The problem seemed intermittent and not reliably reproducible. But I think I found a way to reproduce this problem on demand (at least for the time being). I have an ssh session to another box, on which I run '/usr/bin/nm somelib.so'. After a page or two of output the terminal hangs. At this point nfe0 becomes unresponsive. This is a known problem, but probably unfixable due to lack of documentation from nvidia. See http://cvs.openbsd.org/cgi-bin/query-pr-wrapper?full=yesnumbers=5108
OT: requesting updates to OpenBSD Server Compatibility List
As some of you know, there is a hardware compatibility list at http://www.armorlogic.com/oscl which provides information about major/stock hardware and OpenBSD compatibility. Some of the previously tested configuration are badly out-of-date or are misinformative. Especially the configurations that didn't work a couple of releases ago. They probably work just fine know, but it would be nice if could get confirmation. So please, have a look at the list and send directly to me or to [EMAIL PROTECTED] Especially for the configuration listed with partial support. New configurations and updates to the already working ones are also very welcome. Thanks.
Re: openbsd and dell PE 860 1u rack server
i am considering a Dell PE 860 1u rack server for usage as my network storage server (nfs). I wonder about reports from the openbsd comunity using it with openbsd 4.0/4.1 on stability and performance. What you guys/girls have to report? It is worth its price? I don't run one myself, but got several reports of happy users running OpenBSD on it. Have a look at http://www.armorlogic.com/oscl
Re: Bottleneck in httpd. I need help to address capacity issues on max parallel and rate connections
On 5/9/07, Daniel Ouellet [EMAIL PROTECTED] wrote: I increase the number of contiguous connection only by 5, from 305 to 310, and you get 3 times slower response for always the same thing and repeated all the time. Very consistent and from different clients as well. You can do any variation of 10 to 300 connections and you will always get the same results, or very close to it. See that at the end as well for proof. So, I know I am hitting a hard limit someplace, but can't find where. You've assumed that Apache is the bottleneck, but perhaps your benchmark tool could be limited in some way. I suggest you try with apache benchmark or some other tool just to verify the results. Apache (especially in the prefork model) is known to have concurrency issues. I doubt that there are knobs you can twist OpenBSD-wise that will compensate for Apache and somehow magically make it scale.
Re: dmesg output Sun Fire 4200
On 5/3/07, Daniel Ouellet [EMAIL PROTECTED] wrote: If I may ask, how the Sun Integrated Lights Out Manager (ILOM) on this X4100 box compare to the regular LOM of the Sparc 64 series? Power cycle and possible to do full remote install via console as well like the regular Sun? I don't know how LOM works on USIII boxes, but those on X4200 allow you complete control. You can (via Java based remote console) gain full control of the box. Ie. reboot, shutdown, access OpenBSD's console, install remotely, even mount an ISO image locally on your PC and install OpenBSD on it. Pretty much anything you ever wanted. And ILOM is on a dedicated network interface. Not like the X2100 shared crap.
Re: Widescreen flat panel
On 3/31/07, Eric Dillenseger [EMAIL PROTECTED] wrote: I tried different ModeLine generators from the net, and tried to do it myself using Xorg' logfile. Not helping me out. I have a Dell 20 inch monitor and it works fine with it's native 1680x1050. I had to tweak the Modeline manually but eventually got it to work. On a oldish S3 card though. But it just might work for you too. Section Monitor Identifier Monitor0 VendorName DEL ModelNameDELL 2007WFP #HorizSync30.0 - 83.0 #VertRefresh 56.0 - 76.0 Option DPMS ModeLine[EMAIL PROTECTED] 119.0 1680 1728 1760 1840 1050 1053 1059 1080 -HSync +VSync EndSection
Re: Problem with /sys
On 3/2/07, Victor Abeytua [EMAIL PROTECTED] wrote: Trying to solve this problems I've noticed that the /sys link is broken. In other words, directory /usr/sys doesn't exist. Probably this has to be an installation error, but I would like to know if there is someway to fix, that is, without having to reinstall the box. /sys is a symlink to /usr/src/sys (and not /usr/sys) where kernel sources are typically installed. Since you (probably) didn't install them, /sys points to a non-existing directory. Don't worry. Nothing is broken. Regarding your interface falling problem, you need to provide more details. Don't forget to include the dmesg.
Re: Max amount of RAM
On 3/1/07, Brian Martinez [EMAIL PROTECTED] wrote: I was curious about the maximum amount of RAM an OpenBSD system will recognize. Is there any way at all to get it to recognize more? Kernel recompile? Sysctl options? No. However, you can compile an i386 kernel with PAE which should recognize all of your RAM. I tested an IBM x336 with ~5GB and it worked nicely. Look at http://www.armorlogic.com/oscl/ under IBM x336 (the last dmesg). Don't get fooled by avail memory reporting less. It's just a bug. OpenBSD sees and uses all the RAM. That said, I know a lot of PAE work has been backed out recently (due to an untrackable bug) so this might not even work in -current. YMMV. Also, amd64 only supports 4GB, but there is some work going on to support more.
Re: Clock running 1/4 of real time
I have a 326m running 3.9/amd64 for months without a glitch. Dmesg below. Perhaps something changed after 3.9 that causes the before mentioned problems. OpenBSD 3.9-stable (GENERIC.MP) #7: Mon Aug 21 10:28:18 CEST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2146410496 (2096104K) avail mem = 1835245568 (1792232K) using 22937 buffers containing 214847488 bytes (209812K) of memory mainbus0 (root) ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca2/2 spacing 1 mainbus0: Intel MP Specification (Version 1.4) (AMD HAMMER ) cpu0 at mainbus0: apid 0 (boot processor) cpu0: Dual Core AMD Opteron(tm) Processor 275, 2194.83 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 cpu0: apic clock running at 199MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Dual Core AMD Opteron(tm) Processor 275, 2194.50 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,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative 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 7 is type PCI mpbios: bus 8 is type PCI mpbios: bus 9 is type ISA ioapic0 at mainbus0 apid 4: pa 0x8373ae24, version 11, 16 pins ioapic1 at mainbus0 apid 5: pa 0x8373ad24, version 11, 16 pins ioapic2 at mainbus0 apid 6: pa 0x8373ac24, version 11, 16 pins pci0 at mainbus0 bus 0: configuration mode 1 ppb0 at pci0 dev 1 function 0 ServerWorks HT-1000 PCI rev 0x00 pci1 at ppb0 bus 1 ppb1 at pci1 dev 13 function 0 ServerWorks HT-1000 PCIX rev 0xb2 pci2 at ppb1 bus 2 mpi0 at pci2 dev 3 function 0 Symbios Logic 53c1030 rev 0x08: apic 5 int 2 (irq 11) scsibus0 at mpi0: 16 targets sd0 at scsibus0 targ 0 lun 0: IBM-ESXS, MAX3036NC FN, CA06 SCSI4 0/direct fixed sd0: 34715MB, 49158 cyl, 2 head, 723 sec, 512 bytes/sec, 71096640 sec total safte0 at scsibus0 targ 8 lun 0: IBM, 25P3495a S320 1, 1 SCSI2 3/processor fixed mpi0: target 0 Sync at 160MHz width 16bit offset 127 QAS 0 DT 1 IU 1 pchb0 at pci0 dev 2 function 0 ServerWorks HT-1000 rev 0x00 pciide0 at pci0 dev 2 function 1 ServerWorks HT-1000 IDE rev 0x00: DMA atapiscsi0 at pciide0 channel 0 drive 0 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0: HL-DT-ST, CD-ROM GCR-8240N, 1.06 SCSI0 5/cdrom removable cd0(pciide0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 0 pcib0 at pci0 dev 2 function 2 ServerWorks HT-1000 LPC rev 0x00 ohci0 at pci0 dev 3 function 0 ServerWorks HT-1000 USB rev 0x01: apic 4 int 10 (irq 10), version 1.0, legacy support usb0 at ohci0: USB revision 1.0 uhub0 at usb0 uhub0: ServerWorks OHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ohci1 at pci0 dev 3 function 1 ServerWorks HT-1000 USB rev 0x01: apic 4 int 10 (irq 10), version 1.0, legacy support usb1 at ohci1: USB revision 1.0 uhub1 at usb1 uhub1: ServerWorks OHCI root hub, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ehci0 at pci0 dev 3 function 2 ServerWorks HT-1000 USB rev 0x01: apic 4 int 10 (irq 10) usb2 at ehci0: USB revision 2.0 uhub2 at usb2 uhub2: ServerWorks EHCI root hub, rev 2.00/1.00, addr 1 uhub2: 4 ports with 4 removable, self powered vga1 at pci0 dev 4 function 0 ATI ES1000 rev 0x01 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb2 at pci0 dev 6 function 0 ServerWorks HT-2000 PCIX rev 0xa3 pci3 at ppb2 bus 3 ppb3 at pci0 dev 7 function 0 ServerWorks HT-2000 PCIX rev 0xa3 pci4 at ppb3 bus 4 bge0 at pci4 dev 4 function 0 Broadcom BCM5780 rev 0x03, BCM5714 B3 (0x8003): apic 5 int 10 (irq 7), address 00:11:25:c4:48:a6 brgphy0 at bge0 phy 1: BCM5780 10/100/1000baseT PHY, rev. 0 bge1 at pci4 dev 4 function 1 Broadcom BCM5780 rev 0x03, BCM5714 B3 (0x8003): apic 5 int 11 (irq 12), address 00:11:25:c4:48:a7 brgphy1 at bge1 phy 1: BCM5780 10/100/1000baseT PHY, rev. 0 ppb4 at pci0 dev 8 function 0 ServerWorks HT-2000 PCIE rev 0xa3 pci5 at ppb4 bus 5 ppb5 at pci0 dev 9 function 0 ServerWorks HT-2000 PCIE rev 0xa3 pci6 at ppb5 bus 6 ppb6 at pci0 dev 10 function 0 ServerWorks HT-2000 PCIE rev 0xa3 pci7 at ppb6 bus 7 ppb7 at pci0 dev 11 function 0 ServerWorks HT-2000 PCIE rev 0xa3 pci8 at ppb7 bus 8 pchb1 at pci0 dev 24 function 0 AMD AMD64 HyperTransport rev
Re: ESX crash
On 2/21/07, Craig Barraclough [EMAIL PROTECTED] wrote: Running inside VMware ESX2.5.1, kernel from 16FEB, I was just getting ready to gather info on why the box was crashing with vic(4) enabled, and this crash happened. vic(4) apparently has issues. It crashes on VMware Server 1.01 running Linux as the host. I suggest you try a different emulation. e1000 (as in em(4)) works fine for me. pcn(4) has issues in 4.0-STABLE which should be fixed in -current. BTW if anyone has a good way of getting this info out of virtual machines, I'd love to know - this was all copied out by hand. You can get serial access to the VMware guest console by adding a virtual named pipe (at least on VMware server) and connecting thru that. You'll need a terminal program capable connecting to named pipes or using some tcp - named pipe proxy.
Re: OpenBSD/amd64 on VMware = sloooooow?
According to VMware, you'll need AMD64 CPUs that are made using 90nm. That should be the only requirement. I too test my 64-bit OpenBSD guests on a Linux host running CentOS 4.4 (2.6.9-42.0.2.EL kernel). i386 works like a charm. amd64 performs like a VAX. However, I've tested NetBSD/amd64 (2.0 I think) and that worked just fine. If I remember correctly, the performance problem manifests itself when there is forking involved. If you run CPU intensive jobs (like openssl speed), the performance is fine. If you do a ./configure on a port (which forks processes all the time), it drops to VAX speeds. I'll gladly test any suggestions. Here is output of /proc/cpuinfo from my Linux host: [EMAIL PROTECTED] ~]$ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 47 model name : AMD Athlon(tm) 64 Processor 3200+ stepping: 2 cpu MHz : 1994.273 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow pni bogomips: 3993.80 TLB size: 1088 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp [4] [5]
Re: OpenBSD/amd64 on VMware = sloooooow?
Just to follow up with some basic numbers. I run a perl program which
executes uname -a 20 times while running vmstat 1 in another
terminal. Notice vmstat reporting blocked processes in the run. Output
below.
$ time perl -e 'for($i=0;$i20;$i++) { print $i: .`uname -a`; }'
0: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
1: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
2: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
3: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
4: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
5: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
6: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
7: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
8: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
9: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
10: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
11: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
12: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
13: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
14: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
15: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
16: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
17: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
18: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
19: OpenBSD amd64.lab.armorlogic.com 4.0 GENERIC#690 amd64
0m10.91s real 0m8.68s user 0m0.90s system
$ vmstat 1
procs memorypagedisk traps cpu
r b wavmfre flt re pi po fr sr sd0 int sys cs us sy id
0 0 0 7576 192244 143 0 0 0 0 0 2 230 211 19 11 3 86
0 0 0 7576 19224415 0 0 0 0 0 0 247516 17 5 78
1 0 0 8524 191692 334 0 0 0 0 0 0 235 643 25 74 20 6
1 1 0 8800 191364 252 0 0 0 0 0 0 229 680 18 75 25 0
1 1 0 8884 191300 365 0 0 0 0 0 0 230 551 29 82 18 0
1 1 0 8904 191276 472 0 0 0 0 0 0 231 664 36 84 15 1
1 1 0 8880 191308 593 0 0 0 0 0 0 231 702 44 82 18 0
1 1 0 191292 442 0 0 0 0 0 0 231 580 35 85 15 0
2 0 0 8892 191296 450 0 0 0 0 0 0 226 604 34 78 22 0
1 1 0 191296 628 0 0 0 0 0 0 233 796 45 82 18 0
1 1 0 8896 191292 660 0 0 0 0 0 0 233 858 43 88 12 0
1 1 0 8900 191288 440 0 0 0 0 0 0 236 592 34 82 18 0
0 0 0 7576 192244 288 0 0 0 0 0 0 235 465 33 52 14 33
0 0 0 7576 192244 7 0 0 0 0 0 0 237195 3 2 95
Re: prepping for big spamd(8) rollout
tried i386 with PAE, during dmesg it has: real mem = 12884197376 (12582224K) avail mem = 2784165888 (2718912K) You should have all the RAM (from real mem) available. It's just reporting on avail mem on boot that's not entirely correct. That's what mickey@ told me at least.
Re: prepping for big spamd(8) rollout
On 12/1/06, jared r r spiegel [EMAIL PROTECTED] wrote: working on getting a dual core dual cpu 64b 2MB cache xeon 2.8GHz w/12GB RAM and dual copper em(4) put in place in front of our MX vip for a greylisting spamd(8). i've got a similar machine with faster CPU ( 3.0 GHz / 4MB ) but it only has 4GB of RAM with 4.0 installed on it now that was planning on using but i'm wondering if i'm going to definately need that extra 8GB of RAM. Remember that you'll need to run i386 (with PAE kernel) if you want more than 4GB of RAM. AFAIK, amd64 does not support 4GB, unless that patch from tech@ somehow sneaked into the tree without me noticing.
Re: Sun x4100 amd64 dies with NMI under heavy network load
The system seems to run stable until I put load on the multiport fiber adapter. I recompiled the entire operating system with no issues. Try moving the adapter to another port. Also, some fixes went into -current recently fixing some em(4) issues. You could be hitting a bug. Did you get serial working on your x4200 boxes? I tried not configuring the OpenBSD serial console and using BIOS redirection, that didn't work. I also tried disabling BIOS redirection and configuring explicit OpenBSD serial console support, but still nothing showed up when I connected to the remote management console interface. The only thing I haven't tried is physically connecting to the local serial port on the hardware itself. If I remember correctly, only via the built-in serial port. You might want to get that working and provide a trace/ps when your system panics.
Re: Sun x4100 amd64 dies with NMI under heavy network load
I have deployed several X4200 on 3.9 (with mpi(4) backported from 4.0). AFAIK, X4200 == X4100. It just has some more PCI slots. When booting, RTC BIOS diagnostic error 2 is displayed, I'm not sure if that's relevant. You might want to investigate that. Not sure, but I don't remember seeing that error on the X4200 boxes I had tested. BIOS update might be relevant. Perhaps it's also caused by bad hardware. I have not seen any stability problems with my X4200 deployments. They are not running as network firewalls, but as application level proxies, so the error you are seeing could be due to higher pps count. Unlike you, I didn't put anything non-stock in the box. 4 built-in NICs where enough for my purposes. After the NMI, the system is at the ddb prompt, but the virtual console is unresponsive and I can't type anything at it. So far I haven't been able to get the serial console working, so I'm not sure if the unresponsiveness is due to the USB virtual console, or if the system is just plain hung up. USB layer doesn't work in ddb so you'll need the serial working to get useful debug data.
hardware: IBM x3455 test reports
IBM changed their entire (almost) lineup of X-series servers. It seems that most of the SCSI/SAS variants now have ServeRAID/Adaptec chips, which makes them unusable on OpenBSD. X3455, oddly, has an LSI1064 SAS and should work fine. Anyways, I got my hands on one with SATA. And it just works. Even IPMI works (previous IBM boxes had quirks). As always, more info on http://www.armorlogic.com/oscl OpenBSD 4.0 (GENERIC.MP) #967: Sat Sep 16 20:38:15 MDT 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3488210944 (3406456K) avail mem = 2990272512 (2920188K) using 22937 buffers containing 349028352 bytes (340848K) of memory mainbus0 (root) bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xcff6c000 (51 entries) bios0: IBM IBM System x3455-[798452Y]- ipmi0 at mainbus0: version 2.0 interface KCS iobase 0xca8/8 spacing 4 mainbus0: Intel MP Specification (Version 1.4) (BRCM EXPLOSION ) cpu0 at mainbus0: apid 0 (boot processor) cpu0: Dual-Core AMD Opteron(tm) Processor 2218, 2593.84 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 cpu0: apic clock running at 199MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Dual-Core AMD Opteron(tm) Processor 2218, 2593.50 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,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu2 at mainbus0: apid 2 (application processor) cpu2: Dual-Core AMD Opteron(tm) Processor 2218, 2593.50 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,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu2: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu3 at mainbus0: apid 3 (application processor) cpu3: Dual-Core AMD Opteron(tm) Processor 2218, 2593.50 MHz cpu3: 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 cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu3: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative mpbios: bus 0 is type PCI mpbios: bus 1 is type PCI mpbios: bus 2 is type PCI mpbios: bus 3 is type ISA ioapic0 at mainbus0 apid 4 pa 0xfec0, version 11, 16 pins ioapic1 at mainbus0 apid 5 pa 0xfec01000, version 11, 16 pins ioapic2 at mainbus0 apid 6 pa 0xfec02000, version 11, 16 pins pci0 at mainbus0 bus 0: configuration mode 1 ppb0 at pci0 dev 1 function 0 ServerWorks HT-1000 PCI rev 0x00 pci1 at ppb0 bus 1 ppb1 at pci1 dev 13 function 0 ServerWorks HT-1000 PCIX rev 0xc0 pci2 at ppb1 bus 2 bge0 at pci2 dev 1 function 0 Broadcom BCM5704C rev 0x10, BCM5704 B0 (0x2100): apic 5 int 2 (irq 11), address 00:14:5e:55:13:7f 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 5 int 1 (irq 5), address 00:14:5e:55:13:80 brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 pciide0 at pci1 dev 14 function 0 ServerWorks HT-1000 SATA rev 0x00: DMA pciide0: using apic 4 int 7 (irq 7) for native-PCI interrupt pciide0: port 0: device present, speed: 1.5Gb/s wd0 at pciide0 channel 0 drive 0: WDC WD800JD-23LSA0 wd0: 16-sector PIO, LBA48, 76324MB, 156312576 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 pciide0: port 1: PHY offline pciide0: port 2: PHY offline pciide0: port 3: PHY offline piixpm0 at pci0 dev 2 function 0 ServerWorks HT-1000 rev 0x00: polling iic0 at piixpm0: disabled to avoid ipmi0 interactions pciide1 at pci0 dev 2 function 1 ServerWorks HT-1000 IDE rev 0x00: DMA pcib0 at pci0 dev 2 function 2 ServerWorks HT-1000 LPC rev 0x00 ohci0 at pci0 dev 3 function 0 ServerWorks HT-1000 USB rev 0x01: apic 4 int 10 (irq 10), version 1.0, legacy support usb0 at ohci0: USB revision 1.0 uhub0 at usb0 uhub0: ServerWorks OHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ohci1 at pci0 dev 3 function 1 ServerWorks HT-1000 USB rev 0x01: apic 4 int 10 (irq 10), version 1.0, legacy support usb1 at ohci1: USB revision 1.0 uhub1 at usb1 uhub1: ServerWorks OHCI root hub, rev 1.00/1.00,
Re: hardware: IBM x3455 test reports
IBM changed their entire (almost) lineup of X-series servers. It seems that most of the SCSI/SAS variants now have ServeRAID/Adaptec chips, which makes them unusable on OpenBSD. X3455, oddly, has an LSI1064 SAS and should work fine. Just to correct myself. x3200 and x3250 (both available with either Penitum D and XEON) also come with LSI1064e SAS/SATA controllers. The rest of boxes have either Adaptec AIC-9580W or AIC-9410. All the gory details at http://www-03.ibm.com/servers/eserver/education/cust/xseries/xref/usxref.pdf
Re: Sun x4100 amd64 virtual console -- uhidev0: bad input length 8 != 0
#ifdef DIAGNOSTIC if (scd-sc_in_rep_size != cc) printf(%s: bad input length %d != %d\n,USBDEVNAME(sc-sc_dev), scd-sc_in_rep_size, cc); #endif A more correct fix is to change the line to something like this. It's still not the most correct fix, but does it for me. Most of the debug statements in uhidev.c are wrapped undef #DIAGNOSTICS anyway, but this one was somehow left out. - printf(%s: bad input length %d != %d\n,USBDEVNAME(sc-sc_dev), - scd-sc_in_rep_size, cc); + DPRINTF((%s: bad input length %d != %d\n,USBDEVNAME(sc-sc_dev), + scd-sc_in_rep_size, cc)); As stated before, the keyboard on ILOM seems to works just fine.
Re: USB hard drives
On 9/20/06, Rafael Morales [EMAIL PROTECTED] wrote: I use OpenBSD 3.8 on a Powerbook G4, and when I connect my USB external hard drive, this is my output: Sep 20 12:10:41 Apocalypsis /bsd: umass0 at uhub0 port 1 configuration 1 interface 0 Sep 20 12:10:43 Apocalypsis /bsd: Sep 20 12:10:43 Apocalypsis /bsd: umass0: Prolific Technology Inc. Mass Storage Device, rev 2.00/1.00, addr 2 Sep 20 12:10:43 Apocalypsis /bsd: umass0: using SCSI over Bulk-Only Sep 20 12:10:43 Apocalypsis /bsd: scsibus1 at umass0: 2 targets But how can I mount it ??? http://www.openbsd.org/faq/faq14.html#flashmem
Re: Sun x4100 and MP kernel
On 8/10/06, Russell McGregor [EMAIL PROTECTED] wrote: Having said that, I will still try loading an amd64 snapshot and see if that boots MP. Unless something changed after 3.9, it both boots and runs MP fine, also under heavy load. I tested on x4200, but it should be the same for 4100. Have a look at http://www.armorlogic.com/oscl/
Re: Tuning OpenBSD network throughput
You can try netperf. It works fine. Snippet below shows the results of the network thruput between 2 Opteron boxes running 3.9 with bge/em gigabit cards. [EMAIL PROTECTED]:/home/ssehic$ netperf -H x2100 -l 300 -- -s 64K -m 64K -M 64K -S 64K TCP STREAM TEST to 192.168.0.61 Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 65536 65536 65536300.01 936.58
Re: Sun x4100 and MP kernel
On 8/9/06, Russell McGregor [EMAIL PROTECTED] wrote: I am doing some testing on a Sun x4100 on loan to us from a vendor, I have loaded up a snapshot from about 20060803 and everything seems to run fine from the standard /bsd kernel image, but it panics when trying to boot bsd.mp. I updated src with a CVS checkout earlier today and rebuilt kernels and system, and I am seeing the same issue. I suggest you try amd64 on the box. That should work fine.
Re: reboot on IBM xSeries 336
This is know. Workaround is to install via FTP (with pcibios disabled) or use amd64 version. That, AFAIK, works fine. More details at http://www.armorlogic.com/openbsd_information_server_compatibility_list.html?action=detailid=x336 On 8/1/06, riwanlky [EMAIL PROTECTED] wrote: Hai All, I am trying to install OpenBSD 3.9 GENERIC into IBM xSeries 336, however it reboot after pcibios0: exclusive interrupt 9 10 11 15 The I tried to disable the pcibios0 boot boot -c UKC disable pcibios0 creating partition ok. when it look for cd to install, it did not recognize cd0. Timeout. Perhaps because the cdrom is in pcibios0? I do not have serial cable with me, so I could not display the message. Thanks, Riwan
Re: nfe driver and Sun X2100
On 6/8/06, stan [EMAIL PROTECTED] wrote: Has anyone gotten teh nfe port on a Sun 2100 to work on 19M? I have one of these, that I am setting up as a firewall between 2 legacy networks, both of which are 10M, and when I plug that port into the 10M hub, I get continuing kernel error messages. I'm considering locking it down, to se if that works, but have not tried that yet. AFAIK, phy on that nfe *does not* support 10mbit.
Re: ioapic0 degraded performance - another dmesg
Try to disable pcibios via boot -c bsd.mp. Worked for me in several occasions. On 5/28/06, Antoine Jacoutot [EMAIL PROTECTED] wrote: On Sun, 28 May 2006, Christian Pedaschus wrote: Just finished fun/test installing 3.9 mp on a x4000 and seeing the same message. Glad to know I'm not the only one ;)
hardware: updates to OpenBSD server compatibility list
Just wanted to let you know that OpenBSD server compatibility list has recently been updated with our 3.9-stable (and some -current) test results on a couple of standard servers. Boxes updated with 3.9 test results include: - IBM xServer 336 (new entry) - IBM eServer 326m - Sun x2100 - Dell SC1425 I encourage people to send in test results for the servers listed (or any other stock server from the listed vendors) so we can share with all the others. Detailed information: http://www.armorlogic.com/oscl/
Re: Laptop recommendations
On 5/11/06, Didier Wiroth [EMAIL PROTECTED] wrote: Hello, I'm currently using a thinkpad 60s Dual booting between xp and current, yes currently still required ;-)) see below Here is a short rundown: a) Performance is nice with bsd kernel, performance is degraded with bsd.mp b) sound chip currently not supported c) intel wireless lan currently not supported d) speedstep currently not supported e) power management currently not supported I guess you luck is changing. Your soundchip shoud be supported in -current. http://www.openbsd.org/cgi-bin/man.cgi?query=azalia
Re: PS/2 keyboard failing on generic MP-kernel (Dell SC1425)
I can confirm that PS/2 keyboard also stops responding with MP kernels (3.9-STABLE/amd64) on Dell SC1425. However, USB keyboards work fine. Use that instead.
Re: dell 2650 (-current)
On 5/2/06, Okan Demirmen [EMAIL PROTECTED] wrote: Hi - So I have this wierd problem, which is duplicated on 3 identical machines, where I get a bunch of bmc_io_wait fails messages (see the end of the dmesg). The longer the machine is on, the more messages get tacked on. I'm wondering what this could be. Any ideas/hints? Something similar happened to me with X4200. marco@ committed a fix which disables any found iic sensors if ipmi is present. This is seen in your message as: iic0 at piixpm0: disabled to avoid ipmi0 interactions Try to disable ipmi on boot, and see if your problems go away. You should see some sensors in hw.sensors provided by piixpm. Or, try to disable iic on boot as well. I'm sure marco@ will offer a much better answer.
Re: Thinkpad x60s errata(bsd.mp): ioapic0: pin 11 shares different IPL interrupts (40..50), degraded performance
While booting bsd.mp I noticed the following output: ioapic0: pin 11 shares different IPL interrupts (40..50), degraded performance Disable pcibios (boot bsd.mp -c; disable pcibios; quit;) and see if the degraded performance message goes away. I bet it will, and your bsd.mp performance problems will do too.
Re: Sun X2100
Look at: http://www.armorlogic.com/openbsd_information_server_compatibility_list.html?action=detailid=x2100 The only *real* issue left is the nvidia network card puking under major load, but that might have been solved by the last commit (past 3.9-STABLE) by [EMAIL PROTECTED] I haven't got my hands on this box again to test though.
Re: Server Compatibility List
On 4/19/06, Jonathan Gray [EMAIL PROTECTED] wrote: That is totally out of date for 3.9, everything except the x4200 should be fine. Yes. Especially the HP hardware, since most of the problems were caused by missing PCI bridges that should be fixed now. As soon as I get my 3.9 CDs from Wim, we'll retest some of the boxes.
Re: 3.9 release: nfe driver doesn't work with my motherboard
On 4/15/06, Jurjen Oskam [EMAIL PROTECTED] wrote: nfe0: tx v2 error 0x6004 nfe0 at pci0 dev 10 function 0 NVIDIA CK804 LAN rev 0xa3: irq 3, address 00:13:d4:ae:99:b7 eephy0 at nfe0 phy 9: Marvell 88E Gigabit PHY, rev. 2 That's weird, since nfe(4) worked fine in the X2100 Sun box I tested a while ago. That was pre-3.9. From X2100 dmesg: nfe0 at pci0 dev 10 function 0 NVIDIA CK804 LAN rev 0xa3: apic 2 int 3 (irq 3), address 00:e0:81:58:b1:10 eephy0 at nfe0 phy 1: Marvell 88E Gigabit PHY, rev. 2 Exactly like yours, though the small? phy difference. Could you try with an MP kernel?
Re: OpenBSD 3.9 stable from cvs
On 4/14/06, Nick Holland [EMAIL PROTECTED] wrote: http://www.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.sbin/sendmail/libsm/fflush.c OPENBSD_3_9_BASE is tagged...and that's it. (well..usually. I'm sure there's some exception somewhere...) The patches were put into OPENBSD_3_9 (a.k.a., stable), it turns out. That's not at all usual, and rather surprised me. Apparently, this is a Special Case. No. All patches past the _BASE tag always go into -STABLE. In this case, correctly into OPENBSD_3_9. This is not special AFAIK.
Re: OpenBSD 3.9 stable from cvs
On 4/14/06, Nick Holland [EMAIL PROTECTED] wrote: No. All patches past the _BASE tag always go into -STABLE. In this case, correctly into OPENBSD_3_9. This is not special AFAIK. *sigh* HELLO... Topic is WHEN they go in. 3.9 is not official yet. This patch set went into -stable already. That *is* unusual. So you say that the patch should go into OPENBSD_3_9 branch after 3.9 is *officially* released? Well, I wonder how people who pre-orded their CDs, got them, installed 3.9-RELEASE and run Sendmail are going to patch their systems? Wait for 3.9 to hit FTP mirrors? No. They sync to -rOPENBSD_3_9 and get the patch.
Re: odd dmesg
On 4/3/06, Brian [EMAIL PROTECTED] wrote: I just did a fresh install of 3.9-current. And part of the dmesg is coming across oddly. I am not sure what else to say about it. It's the iic0 and iic1. It's just the new sensors framework telling you that it has encountered an unsupported sensor in your machine. The output is for developers in case they want to add support for it.
Re: SAS controllers?
I personally tested a DL360 G4 with SAS/P600 and it worked like a charm (after a small patch I've sent; this is in 3.9-STABLE). Actually, ciss(4) doesn't really care if the controller is SAS or not. It just works, unlike LSI mpt(4). There is some hacking going on to add SAS support for it. If all goes well, that will make it into 4.0. On 4/3/06, Bill Marquette [EMAIL PROTECTED] wrote: 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 ;)
Re: Cavium crypto card
Has anybody a 'High performance IPSec and SSL accelerator PCI card with Cavium CN1010' running on OpenBSD? I am looking for a crypto card and it could be an option but it isn't in the hardware supported list in http://www.openbsd.org/i386.html#hardware Some crypto cards are based on a supported chip, but are simply re-branded. I took a brief look at the Cavium and it looks like they have their own chips. We don't have support for those. They also state they have drivers for FreeBSD. Perhaps you can talk them into making an BSD-licensed OpenBSD driver or donating specs/cards to the project and someone might offer to write a driver. There is some (slow) work going on to support newer chips from Safenet. I guess you can call them high-performance, since they claim that the new chips can do 1gbps symmetric crypto ops. The problem with crypto cards is moving data in and out from the kernel. But, that's another story.
Re: DRAV vs iLo
Who wins in the OpenBSD world? DRAC (Dell Remote Admin Card) or iLo (HP's Integrated Lights Out)? We're looking at new servers and are wondering if these are worth the cash, or which is the one to go for? I've never used DRAC, but ILO (the real deal, like in HP360G4) is pretty solid. Stay away from the el-cheapo variants found in DL145 and the like. You might want to purchase the Advanced pack, since that gives you fancy stuff like remote ISO mount from you workstation. I've also used Sun's ILOM. HP's is still better IMHO.
Re: LSI SAS1064 support in OpenBSD?
Is anyone working on supporting the SAS-versions of the LSI controllers at the moment, or should I look for a different server for the time being? AFAIK, dlg@ is working on it.
Re: HP ProLiant DL 385
On 3/14/06, edgarz [EMAIL PROTECTED] wrote: Looks good! but what is that: Compaq iLO rev 0x01 at pci1 dev 2 function 0 not configured Compaq iLO rev 0x01 at pci1 dev 2 function 2 not configured That's just Integrated Lights Out stuff. You don't need that from OpenBSD. And yes, we are going to re-test all HP hardware on the OSCL (when the time permits). The problem with a lot of HP hardware was actually caused by some PCI bridges not being properly detected. Those should be fixed by kettenis@ and brad@ in -current and 3.9-RELEASE/STABLE.
Re: Low-cost 1U server
On 3/14/06, Bryan Allen [EMAIL PROTECTED] wrote: Sunfire X2100? They're Opterons, not Pentiums, but... Has issues, but has no showstoppers. Unless you put your nfe(4) card under stress. Look at http://www.armorlogic.com/oscl/ for all the details.
Re: HP ProLiant DL 385
On 3/14/06, edgarz [EMAIL PROTECTED] wrote: I will be a very happy if those two servers (DL 145 and DL 385) will work. Means hardware will detect and work without strange things, like a slow hdd system, unusable raid or similar crap :) I would choose the SCSI version of DL145 G2, since SATA has performance issue (around 6MB/sec read/write with dd). It could be fixed in 3.9. I dunno.
Re: Slow SCSI HDD (HW RAID) on Dual Xeon
You're lucky that your RAID1 array even works, since integrated mirroring (IM) is currently not supported by mpt(4) driver. If it works, it is slow like hell. If you want speed, remove the RAID1 array and run with 2 normal disks. On 3/13/06, Adam Papai [EMAIL PROTECTED] wrote: Hi misc, I've got a problem with the SCSI read/write speed under 3.8. It has LSILOGIC HW raid adapter running raid1.
Re: hardware: Sun x2100 test results
On 2/22/06, Jonathan Gray [EMAIL PROTECTED] wrote: 2) nfe(4) shows a constant 100/interrupts a seconds without having a link; only configured with ifconfig nfe0 127.0.0.1 255.0.0.0; it also has the same interrupt rate when configured normally This should be fixed in -current by damien. Indeed. Just tried with if_nfe.c (r1.47). 0 interrupts/seconds without activity. Also, under the stress test, systat vmstat shows around 55% system idle (r1.47). Previously, it was 0% (r1.45). 3) nfe(4) stops responding during stress-testing with netperf This also possibly. Still happens. Settings the receiver (nfe0) socket buffer size to 256K rendered x2100/nfe0 useless. Still, only a reboot helps. This happened before (r.1.45) with socket buffer of 128K; now, it's just pushed a bit further.
hardware: Sun x2100 test results
For those interested, here are the preliminary results of my Sun x2100 tests. More hardware tests results available at http://www.armorlogic.com/oscl/ Issues with Sun X2100 running OpenBSD/amd64 (-current from 22/02/2006) 1) possible bsd.mp issues due to misconfigured apic's ioapic0 at mainbus0 apid 2: pa 0x83738f24, version 11, 24 pins ioapic0: misconfigured as apic 0 ioapic0: remapped to apic 2 2) nfe(4) shows a constant 100/interrupts a seconds without having a link; only configured with ifconfig nfe0 127.0.0.1 255.0.0.0; it also has the same interrupt rate when configured normally 3) nfe(4) stops responding during stress-testing with netperf (transmitter box, Dell SC1425, dual em/gigabit) (receiver box, Sun X2100, nfe/gigabit) (both connected to a Dell PowerConnect 2708 gigabit switch) # netperf -H 192.168.0.60 -l 300 -- -s 64K -m 64K -M 64K -S 64K TCP STREAM TEST to 192.168.0.60 Recv SendSend Socket Socket Message Elapsed Size SizeSize Time Throughput bytes bytes bytessecs.10^6bits/sec 65536 65536 65536298.96940.67 (transmitter: 8K/interrupts seconds on em0, 0% system idle) (receiver: 83K/interrupts seconds on nfe0, 0% system idle) All fine. Stress test runs for 300 seconds without a problem. Now, we try the same test, but we increase the remote socket (nfe0) send/recv buffer size to 128K. # netperf -H 192.168.0.60 -l 60 -- -s 128K -m 64K -M 64K -S 128K (transmitter: 8K/interrupts seconds on em9, 0% system idle) (receiver: 100K/interrupts seconds on nfe0, 0% system idle) nfe0 will stop responding after few seconds; tcpdump shows nothing; ifconfig down/up doesn't help; only a reboot does. 4) nviic(4) is probed/found, but provides no values to sensors(4) framework. Details follow: nviic0 at pci0 dev 1 function 1 NVIDIA nForce4 SMBus rev 0xa2 iic0 at nviic0 iic0: addr 0x2e 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 09=00 0a=00 0b=00 0c=00 0d=00 0e=00 0f=00 10=00 11=00 12=00 13=00 14=00 15=00 16=00 17=00 18=00 19=00 1a=00 1b=00 1c=00 1d=00 1e=00 1f=03 20=63 21=75 22=c1 23=c1 24=bc 25=38 26=1c 27=19 28=39 29=02 2a=19 2b=03 2c=f5 2d=02 2e=2e 2f=02 30=81 31=55 32=55 33=00 34=00 35=00 36=00 37=00 38=00 39=00 3a=00 3b=00 3c=00 3d=00 3e=5c 3f=89 40=05 41=00 42=00 43=00 44=00 46=00 48=00 4a=00 4c=00 4e=ec 4f=50 50=ec 51=3c 52=ec 53=3c 54=5e 55=1a 56=5e 57=1a 58=5e 59=1a 5a=5e 5b=1a 5c=02 5d=22 5e=42 5f=4b 60=ab 61=ab 62=e8 63=88 64=80 65=33 66=33 67=38 68=2d 69=2a 6a=3e 6b=3a 6c=37 6d=44 6e=40 6f=00 70=80 71=33 72=33 73=09 74=09 75=09 76=09 77=09 78=09 79=00 7a=10 7b=00 7c=44 7d=00 7e=00 7f=1c 80=0f 81=84 82=05 83=00 84=ec 85=9a 86=73 87=1d 88=26 89=00 8a=4d 8b=4d 8c=0b 8d=0b 8e=0c 8f=00 90=84 91=86 92=86 93=84 94=0c 95=0c 96=0c 97=5a 98=f1 99=be 9a=ac 9b=00 9d=00 9f=00 a0=00 a1=00 a2=0c a3=00 a4=02 a5=00 a6=00 a7=0b a8=0b a9=fe ab=fe b1=00 b2=00 b3=00 b4=00 b5=00 b6=28 b7=28 b8=0e b9=0e ba=2b bb=2b bc=00 bd=00 be=00 bf=00 c0=00 c1=00 c2=00 c3=00 c4=00 c5=00 c6=00 c7=00 c8=00 c9=00 ca=00 cb=00 cc=00 cd=00 ce=00 cf=00 d0=00 d1=00 d2=00 d3=00 d4=00 d5=00 d6=00 d7=00 d8=00 d9=00 da=00 db=00 dc=00 dd=00 de=00 df=00 e0=00 e1=00 e2=00 e3=00 e4=00 e5=00 e6=00 e7=00 e8=00 e9=00 ea=00 eb=00 ec=00 ed=00 ee=00 ef=00 f0=00 f1=00 f2=00 f3=00 f4=00 f5=00 f6=00 f7=00 f8=00 f9=00 fa=00 fb=00 fc=00 fd=00 fe=00 ff=00 iic1 at nviic0 iic1: addr 0x2e 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 09=00 0a=00 0b=00 0c=00 0d=00 0e=00 0f=00 10=00 11=00 12=00 13=00 14=00 15=00 16=00 17=00 18=00 19=00 1a=00 1b=00 1c=00 1d=00 1e=00 1f=03 20=63 21=75 22=c1 23=c1 24=bc 25=38 26=1c 27=19 28=39 29=02 2a=1a 2b=03 2c=fb 2d=02 2e=2e 2f=02 30=81 31=55 32=55 33=00 34=00 35=00 36=00 37=00 38=00 39=00 3a=00 3b=00 3c=00 3d=00 3e=5c 3f=89 40=05 41=00 42=00 43=00 44=00 46=00 48=00 4a=00 4c=00 4e=ec 4f=50 50=ec 51=3c 52=ec 53=3c 54=5e 55=1a 56=5e 57=1a 58=5e 59=1a 5a=5e 5b=1a 5c=02 5d=22 5e=42 5f=4b 60=ab 61=ab 62=e8 63=88 64=80 65=33 66=33 67=38 68=2d 69=2a 6a=3e 6b=3a 6c=37 6d=44 6e=40 6f=00 70=80 71=33 72=33 73=09 74=09 75=09 76=09 77=09 78=09 79=00 7a=10 7b=00 7c=44 7d=00 7e=00 7f=1c 80=0f 81=84 82=05 83=00 84=bd 85=95 86=63 87=1d 88=46 89=00 8a=4d 8b=4d 8c=0b 8d=0b 8e=0c 8f=00 90=84 91=86 92=86 93=84 94=0c 95=0c 96=0c 97=5a 98=f1 99=be 9a=ac 9b=00 9d=00 9f=00 a0=00 a1=00 a2=0c a3=00 a4=02 a5=00 a6=00 a7=0b a8=0b a9=fe ab=fe b1=00 b2=00 b3=00 b4=00 b5=00 b6=28 b7=28 b8=0e b9=0e ba=2b bb=2b bc=00 bd=00 be=00 bf=00 c0=00 c1=00 c2=00 c3=00 c4=00 c5=00 c6=00 c7=00 c8=00 c9=00 ca=00 cb=00 cc=00 cd=00 ce=00 cf=00 d0=00 d1=00 d2=00 d3=00 d4=00 d5=00 d6=00 d7=00 d8=00 d9=00 da=00 db=00 dc=00 dd=00 de=00 df=00 e0=00 e1=00 e2=00 e3=00 e4=00 e5=00 e6=00 e7=00 e8=00 e9=00 ea=00 eb=00 ec=00 ed=00 ee=00 ef=00 f0=00 f1=00 f2=00 f3=00 f4=00 f5=00 f6=00 f7=00 f8=00 f9=00 fa=00 fb=00 fc=00 fd=00 fe=00 ff=00 dmesg x2100: OpenBSD 3.9-beta (GENERIC.MP) #0: Wed Feb 22 12:04:50 CET 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2145873920 (2095580K)
Re: IBM e326m SCSI
Look at http://www.armorlogic.com/oscl/. There is an dmesg for e326m/SCSI version. To answer your question. Don't create any kind of logical volume (RAID0/1), just use the physical disks. In short, IM (integrated mirroring) is _not_ supported. It is, however, being worked on. My e326m/SCSI survived several bonnie/iogen disk tests without a hitch. So it should be stable. On 2/9/06, Daniel Ouellet [EMAIL PROTECTED] wrote: I still haven't seen a DMESG for the IBM e326m SCSI version as well as using the RAID 1. Can anyone confirm or deny if it is supported and works well on the current version? I know all issues known for the e326m SATA version are out of the way, but I don't know yet about the SCSI version. DMESG, or any issues known? Thanks for your time!
Re: systat vm question
The latest, which is, AFAIK, 2.58. On 2/8/06, Jason Houx [EMAIL PROTECTED] wrote: Srebrenko, What firmware are you using on your controller? Jason On Wed, 8 Feb 2006, Srebrenko Sehic wrote: You can also try to update to -rOPENBSD_3_8. All noticeable performance problems went away with some important patches since the release. I bet you'll see the load go away. And yes, as Henning said, 200 interrupts/second is nothing. My ciss(4) controllers go up to 5000 interrupts/seconds. But hey, I'm also writing 100 MB/sec, and the load is negligible. On 2/7/06, Jason Houx [EMAIL PROTECTED] wrote: On Tue, 7 Feb 2006, Henning Brauer wrote: * Jason Houx [EMAIL PROTECTED] [2006-02-07 18:53]: Interrupts are at 489 total with CISS0 doing over 200 no, 200 int/s doesn't even remotely smell like a problem. Great thanks for providing me a baseline. I guess I will just try the next snapshot for the improved CISS driver. systat vm is really nice - thanks again for the post. Jason Houx
Re: systat vm question
You can also try to update to -rOPENBSD_3_8. All noticeable performance problems went away with some important patches since the release. I bet you'll see the load go away. And yes, as Henning said, 200 interrupts/second is nothing. My ciss(4) controllers go up to 5000 interrupts/seconds. But hey, I'm also writing 100 MB/sec, and the load is negligible. On 2/7/06, Jason Houx [EMAIL PROTECTED] wrote: On Tue, 7 Feb 2006, Henning Brauer wrote: * Jason Houx [EMAIL PROTECTED] [2006-02-07 18:53]: Interrupts are at 489 total with CISS0 doing over 200 no, 200 int/s doesn't even remotely smell like a problem. Great thanks for providing me a baseline. I guess I will just try the next snapshot for the improved CISS driver. systat vm is really nice - thanks again for the post. Jason Houx
Re: Broadcom BCM5752 NIC
On 2/3/06, Badbanchi Hossein [EMAIL PROTECTED] wrote: Hi, This morning I installed the kernel from the snapshot. The only (cosmetic) difference is that the time-out values are reduced, so it doesn't take that long as before for the system to boot, but the BCM5752 NIC is still not functioning properly! Ok. Try this. Power-off you machine, unplug the cable from the network card and boot the machine with the latest -current snapshot. Look for firmware handshake error message. It seems like that Broadcom network cards, if not initialized properly (this could've happened when you booted 3.8), have to be re-initialized properly in order to function again. This happened on my IBM e326m and the above approach solved the problem.
Re: Broadcom BCM5752 NIC
Try a -current snapshot. Some important bge(4) fixes went into the tree after 3.8. On 2/2/06, Badbanchi Hossein [EMAIL PROTECTED] wrote: Actually the NIC doesn't work properly. I can ssh to the box, but even output of a simple ls command takes seconds to appear on the screen, and gets interrupted in between. Does anyone know of any patch for this? Here is the output of ifconfig: # ifconfig -a lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33224 groups: lo inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:15:60:4f:22:e4 groups: egress media: Ethernet autoselect (100baseTX full-duplex) status: active inet 172.22.11.235 netmask 0xfc00 broadcast 172.22.11.255 inet6 fe80::215:60ff:fe4f:22e4%bge0 prefixlen 64 scopeid 0x1 pflog0: flags=0 mtu 33224 pfsync0: flags=0 mtu 1348 enc0: flags=0 mtu 1536 Thanks for any assistance. Amir -Original Message- From: Badbanchi Hossein Sent: Thursday, February 02, 2006 19:36 To: misc@openbsd.org Subject: Broadcom BCM5752 NIC Hi, Have recently got an HP Compaq dc7600 to be used as DHCP Server. OpenBSD 3.8 install couldn't properly work with the Broadcom BCM5752 NIC! The Error says: bge0: firmware handshake timed out After installation was complete, now each time I reboot the system it takes a long time for the system to boot. It waits during initial boot and a second time while trying to configure the NIC with IP parameters, until it times out (both times with the same error as above). After the boot process is complete the NIC works!! I mean I can ping the box. I haven't tested the throughput of the NIC though. Here is an excerpt from dmesg: # dmesg | grep bge bge0 at pci2 dev 0 function 0 Broadcom BCM5752 rev 0x01, BCM5752 A1 (0x6001): irq 10bge0: firmware handshake timed out brgphy0 at bge0 phy 1: BCM5752 10/100/1000baseT PHY, rev. 0 bge0: firmware handshake timed out # And here is an excerpt from man brgphy: DESCRIPTION The brgphy driver supports Broadcom BCM5400 100/1000TX Ethernet PHY in- terfaces, as well as the BCM5401, BCM5411, BCM5421S, BCM5701, BCM5703, BCM5704, BCM5705, BCM5714, BCM5750 and BCM5752 10/100/1000baseTX Ethernet PHY interfaces. I would greatly appreciate any help? Amir
Re: hardware: IBM e326m test results
Damn, talk about beeing unlucky. My test came 1 day before the new patch. I started to look into this myself. I guess Brad beat me to it. Great work, less work for me :) I'll update the OSCL. Thanks to Daniel as well for testing. On 2/1/06, Brad [EMAIL PROTECTED] wrote: Hey, update the bge driver and retest on your IBM e326m. You'll see a nice surprise. :)
hardware: SunFire X4200 test results
I finally got a hold of a new Sun X4200 Opetron server. Bad news for anybody how likes Sun hardware: our mpt(8) driver doesn't support the SAS/SCSI controller resulting in no go condition. Everything else seems to work. OSCL (OpenBSD Server Compatibilty List) is updated with this information. Find it at: http://www.armorlogic.com/openbsd_information_server_compatibility_list.html dmesg: OpenBSD 3.8-current (RAMDISK_CD) #643: Sat Jan 14 18:27:03 MST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 4160282624 (4062776K) avail mem = 3575197696 (3491404K) using 22937 buffers containing 416235520 bytes (406480K) of memory mainbus0 (root) cpu0 at mainbus0: (uniprocessor) cpu0: Dual Core AMD Opteron(tm) Processor 280, 2395.44 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 1 function 0 AMD 8131 PCIX rev 0x13 pci1 at ppb0 bus 1 em0 at pci1 dev 1 function 0 Intel PRO/1000MT (82546EB) rev 0x03: irq 10, address 00:14:4f:0f:ac:16 em1 at pci1 dev 1 function 1 Intel PRO/1000MT (82546EB) rev 0x03: irq 11, address 00:14:4f:0f:ac:17 em2 at pci1 dev 2 function 0 Intel PRO/1000MT (82546EB) rev 0x03: irq 11, address 00:14:4f:0f:ac:1c em3 at pci1 dev 2 function 1 Intel PRO/1000MT (82546EB) rev 0x03: irq 9, address 00:14:4f:0f:ac:1d AMD 8131 PCIX IOAPIC rev 0x01 at pci0 dev 1 function 1 not configured ppb1 at pci0 dev 2 function 0 AMD 8131 PCIX rev 0x13 pci2 at ppb1 bus 2 Symbios Logic SAS1064 rev 0x02 at pci2 dev 3 function 0 not configured AMD 8131 PCIX IOAPIC rev 0x01 at pci0 dev 2 function 1 not configured ppb2 at pci0 dev 6 function 0 AMD 8111 PCI-PCI rev 0x07 pci3 at ppb2 bus 3 ohci0 at pci3 dev 0 function 0 AMD 8111 USB rev 0x0b: irq 11, 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 pci3 dev 0 function 1 AMD 8111 USB rev 0x0b: irq 11, 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 vga1 at pci3 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 7 function 0 not configured pciide0 at pci0 dev 7 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, DV-28SL, 1.0A SCSI0 5/cdrom removable cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 ignored (disabled) AMD 8111 SMBus rev 0x02 at pci0 dev 7 function 2 not configured AMD 8111 Power rev 0x05 at pci0 dev 7 function 3 not configured pchb0 at pci0 dev 24 function 0 AMD AMD64 HyperTransport rev 0x00 pchb1 at pci0 dev 24 function 1 AMD AMD64 Address Map rev 0x00 pchb2 at pci0 dev 24 function 2 AMD AMD64 DRAM Cfg rev 0x00 pchb3 at pci0 dev 24 function 3 AMD AMD64 Misc Cfg rev 0x00 pchb4 at pci0 dev 25 function 0 AMD AMD64 HyperTransport rev 0x00 pchb5 at pci0 dev 25 function 1 AMD AMD64 Address Map rev 0x00 pchb6 at pci0 dev 25 function 2 AMD AMD64 DRAM Cfg rev 0x00 pchb7 at pci0 dev 25 function 3 AMD AMD64 Misc Cfg rev 0x00 isa0 at mainbus0 com0 at isa0 port 0x3f8/8 irq 4: 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 rd0: fixed, 3584 blocks umass0 at uhub1 port 1 configuration 1 interface 0uhidev0 at uhub0 port 2 configuration 1 interface 0 umass0: American Megatrends Inc. Virtual Cdrom Device, rev 1.10/1.00, addr 2 umass0: using ATAPI over Bulk-Only uhidev0: DELL DELL USB Keyboard, rev 1.10/1.04, addr 2, iclass 3/1 scsibus1 at umass0: 2 targets ukbd0 at uhidev0 wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 uhidev1 at uhub0 port 3 configuration 1 interface 0 uhidev1: American Megatrends Inc. Virtual Keyboard and Mouse, rev 1.10/1.00, addr 3, iclass 3/1 ukbd1 at uhidev1 wskbd2 at ukbd1 mux 1 wskbd2: connecting to wsdisplay0 uhidev2 at uhub0 port 3 configuration 1 interface 1 uhidev2: American Megatrends Inc. Virtual Keyboard and Mouse, rev 1.10/1.00, addr 3, iclass 3/1 uhid at uhidev2 not configured cd1 at scsibus1 targ 1 lun 0: AMI, Virtual CDROM, 1.00 SCSI0 5/cdrom removable umass1 at uhub1 port 2 configuration 1 interface 0 umass1: American Megatrends Inc. Virtual Floppy Device, rev 1.10/1.00, addr 3 umass1: using UFI over CBI with CCI scsibus2 at umass1: 2 targets sd0 at scsibus2 targ 1 lun 0:
Re: hardware: SunFire X4200 test results
On 1/17/06, Bill Marquette [EMAIL PROTECTED] wrote: OSCL (OpenBSD Server Compatibilty List) is updated with this information. Find it at: http://www.armorlogic.com/openbsd_information_server_compatibility_list.html You might want to retest the DL380 G4 - I have dozens of these running 3.5 in production (and 3.8 / 3.8-current run fine on them w/out offboard scsi controllers). The PCI riser definitely works on them. Also, the DL385 has had some recent dmesg's posted by me - they don't work so well, but the onboard controller is certainly not on the riser (which doesn't work) as I was able to install on it. ciss(8) first appeared in 3.8, so you must be running an older 380 variant (not the G4 og G4P) on 3.5. And I agree, 3.8 will probably run on 380 G4/G4P with the onboard RAID controller. The version I had for test, had SAS drives and RAID card in the PCI-X riser board. I'll update the OSCL with that information as well. Thanks.
Re: crash with 3.8 GENERIC.MP#353 on Dell PE 1850
On 12/29/05, Jon Hart [EMAIL PROTECTED] wrote: Great, I'll give that a shot today after I see if I can repeat the crash. Do you happen to know what date the commit was done? I checked MARC and couldn't seem to find the commit from Pedro after 3.8-stable. brad@ is the -STABLE maintainer so try to look that up instead. The actual fix was made by pedro@ in -CURRENT.
Re: crash with 3.8 GENERIC.MP#353 on Dell PE 1850
Also, run a netstat -m and look at peak usage. If that number is reaching max, increase kern.maxclusters with sysctl. $ netstat -m 1543 mbufs in use: 1539 mbufs allocated to data 1 mbuf allocated to packet headers 3 mbufs allocated to socket names and addresses 1538/6152/6144 mbuf clusters in use (current/peak/max) 12732 Kbytes allocated to network (27% in use) 0 requests for memory denied 0 requests for memory delayed 4896 calls to protocol drain routines I thought so. The patch, I believe, is in 3.8-STABLE which allocates mbufs on the fly as they are needed. Try a -current snapshot and see if that helps. Keep the kern.maxclusters at the default. When you hit the limit, it will print a warnings on the console, but will not panic. I guess you can safely double the default value and you should be fine. Don't set it to a ridiculously high number. If the double is not enough for you, then the real problem with network data buffering is somewhere else.
Re: crash with 3.8 GENERIC.MP#353 on Dell PE 1850
Try to increase kern.maxclusters. It is possible that the box crashed due to network buffer shortage. pedro@ commited a fix to both -currentand 3.8-STABLE which increases buffer on-the-fly without panic. Also, run a netstat -m and look at peak usage. If that number is reaching max, increase kern.maxclusters with sysctl. On 12/28/05, Jon Hart [EMAIL PROTECTED] wrote: One of my carp masters crashed last night. Fortunately, the slave immediately picked up and nobody was the wiser.
Re: PCI-X not seen by 3.8 on HP DL-145 G2
On 12/9/05, Uwe Dippel [EMAIL PROTECTED] wrote: So you probably saw mine as well, Proliant 350. I have no solution yet, but a few more boxes rolling in that need more than that single Broadcom on-board piece. Is this a HP problem or an OpenBSD problem ? I'll try Linux on the next box; but surely prefer to run OpenBSD ! If you happen to find a working solution or a working, readily available NIC, please keep me informed ! It seems like a OpenBSD problem. If you are looking for HP hardware to run OpenBSD on, here are some of mine experiences. For the impatient: you will have difficulties finding a latest HP box to run and perform good on OpenBSD unless you go -current. If someone is interested in dmesgs for these systems, please let me know. 1) DL145 (G2), SCSI/mpt = showstopper, OpenBSD can't see the raiser board and hence the LSI controller seated in it (tested on i386/3.8-STABLE and -current) 2) DL145 (G2), SATA/nForce4 = works, but the disk is slow and the CPU spends 100% of time in kernel with heavy disk activity. (tested on i386/3.8-STABLE) 3) DL320 (G3), SATA/Intel 82801FR = works, but the disk is slow and the CPU spends 100% of time in kernel with heavy disk activity. (tested on i386/3.8-STABLE and -current) 4) DL360 (G4/G4p) and DL380 (G4), SCSI/RAID/SmartArray P600/6i/6400 = works (see * below), up kernel = ok; mp kernel = has performance issues; 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) 6) DL580 (G3), SCSI/RAID/SmartArray 64xx = works (see * below); tested on i386/3.8-current, mp, 4 x XEON. Issues with built-in bge cards. 7) BL45P, SCSI/RAID/SmartArray 64xx = works (see * below); tested on amd64/3.8-STABLE, mp, 2 x dual-core Opteron. Box has 4 interfaces; OpenBSD can only see the first 2. * Disk access is slow and the CPU spends 100% of time in kernel with heavy disk activity. Performance is greatly improved in -current and there is support for SAS (Serial Attached Storage) RAID cards as well. Some kernel error messages are printed when the box boots and when you do a newfs.
Re: PCI-X not seen by 3.8 on HP DL-145 G2
On 12/9/05, Pete Vickers [EMAIL PROTECTED] wrote: for my DL145 (pretty new) I get a reasonable-ish disk I/O of ~60Mb/s ( with CPU at 99% idle) [EMAIL PROTECTED] /root dd if=/dev/rwd0a of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 17.645 secs (59423434 bytes/sec) [EMAIL PROTECTED] /root Try testing read/write into files instead of raw device. Also, try with smaller block sizes. I bet you will see different results.
