ifconfig promiscuous mode
Hi, How to enable and disable the promiscuous mode with OpenBSD 4.3. I didn't find the -promisc argument in ifconfig. Thanks M
Re: ifconfig promiscuous mode
On 03:43:49 Nov 18, Man Lam wrote: Hi, How to enable and disable the promiscuous mode with OpenBSD 4.3. I didn't find the -promisc argument in ifconfig. man pcap -Girish
Re: ifconfig promiscuous mode
On Tue, Nov 18, 2008 at 12:43 AM, Man Lam [EMAIL PROTECTED] wrote: How to enable and disable the promiscuous mode with OpenBSD 4.3. I didn't find the -promisc argument in ifconfig. Why would you want to do that manually? Software that needs promiscuous mode should turn it on automatically. Philip Guenther
Re: Issues with FTP and PF
This works. Thanks. Try this: replace this line: pass in on $vpn_if inet proto tcp to $ext_addr port 21 \ flags S/SA keep state with this: pass in on $vpn_if inet proto tcp to $Srv port 21 \ flags S/SA keep state Remember rdr's happen before filtering, so when pf see's this packet it will have already been translated to the server address. If that doesn't fix it, see what is getting logged. J On Mon, Nov 17, 2008 at 2:43 AM, `RIJ dMITRI[IN [EMAIL PROTECTED] wrote: Hi. I have ftp server on vsftpd on ip 192.168.0.2 and a router 192.168.0.1. All ftp connections to 192.168.0.2 are fine but connections to my ext. ip (e.g. 78.78.78.78) are refused. Here's part of my pf.conf: # WAN vpn_if=tun0 # LAN int_if=vr1 # External Address ext_addr=78.78.78.78 # Server IP's Srv=192.168.0.2 # NAT / Redirection nat on $vpn_if from $int_if:network to any - ($vpn_if) # FTP nat-anchor ftp-proxy/* rdr-anchor ftp-proxy/* rdr on $vpn_if proto tcp from any to any port 21 - $Srv rdr on $vpn_if proto tcp from any to any port 3:30099 - $Srv # Actions with FTP pass in on $vpn_if inet proto tcp to $ext_addr port 21 \ flags S/SA keep state pass out on $int_if inet proto tcp to $Srv port 21 \ user proxy flags S/SA keep state anchor ftp-proxy/* Here's my rc.conf.local: ftpproxy_flags=-R 192.168.0.2 -p 21 -b 78.78.78.78 Thanks for your help. -- Best, Yuriy A. Dmitrishin.
IBM T60: ACPI suspend and resume working
I'm trying to get ACPI suspend and resume working. Typing apm -z from my window manager's xterm just returns me back to the shell. Typing apmd and then apm -z tells me System will enter suspend mode momentarily. and then nothing happens. Following is my dmesg. Thanks for any help. OpenBSD 4.4 (GENERIC.MP) #844: Tue Aug 12 17:24:39 MDT 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz (GenuineIntel 686-class) 1.83 GHz cpu0: FPU,V86,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,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR real mem = 526807040 (502MB) avail mem = 500883456 (477MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 04/12/07, BIOS32 rev. 0 @ 0xfd6b0, SMBIOS rev. 2.4 @ 0xe0010 (68 entries) bios0: vendor LENOVO version 79ETD2WW (2.12 ) date 04/12/2007 bios0: LENOVO 1954PJM acpi0 at bios0: rev 2 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 166MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz (GenuineIntel 686-class) 1.83 GHz cpu1: FPU,V86,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,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: duplicate apic id, remapped to apid 2 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus 4 (EXP2) acpiprt5 at acpi0: bus 12 (EXP3) acpiprt6 at acpi0: bus 21 (PCI1) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2 acpicpu1 at acpi0: C3, C2 acpitz0 at acpi0: critical temperature 127 degC acpitz1 at acpi0: critical temperature 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 92P1141 serial 1159 type LION oem SONY acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock at acpi0 not configured acpivideo at acpi0 not configured acpivideo at acpi0 not configured bios0: ROM list: 0xc/0xea00! 0xcf000/0x1000 0xd/0x1000 0xdc000/0x4000! 0xe/0x1! cpu0: unknown Enhanced SpeedStep CPU, msr 0x06130b2506000b25 cpu0: using only highest and lowest power states cpu0: Enhanced SpeedStep 1833 MHz (1292 mV): speeds: 1833, 1000 MHz pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03 vga1 at pci0 dev 2 function 0 Intel 82945GM Video rev 0x03 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) agp0 at vga1: aperture at 0xd000, size 0x1000 drm at vga1 unsupported Intel 82945GM Video rev 0x03 at pci0 dev 2 function 1 not configured azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: apic 2 int 17 (irq 11) azalia0: codec[s]: Analog Devices/0x1981, Conexant/0x2bfa, using Analog Devices/0x1981 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 2 int 20 (irq 11) pci1 at ppb0 bus 2 em0 at pci1 dev 0 function 0 Intel PRO/1000MT (82573L) rev 0x00: apic 2 int 16 (irq 11), address 00:15:58:c3:aa:e0 ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 2 int 21 (irq 11) pci2 at ppb1 bus 3 wpi0 at pci2 dev 0 function 0 Intel PRO/Wireless 3945ABG rev 0x02: apic 2 int 17 (irq 11), MoW1, address 00:1b:77:4d:5a:f4 ppb2 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x02: apic 2 int 22 (irq 11) pci3 at ppb2 bus 4 ppb3 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x02: apic 2 int 23 (irq 11) pci4 at ppb3 bus 12 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 2 int 16 (irq 11) uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 2 int 17 (irq 11) uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 2 int 18 (irq 11) uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 2 int 19 (irq 11) ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x02: apic 2 int 19 (irq 11) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb4 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xe2 pci5 at ppb4 bus 21 cbb0 at pci5 dev 0 function 0 TI PCI1510 CardBus rev 0x00: apic 2 int 16 (irq 11) cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 22 device 0 cacheline 0x8, lattimer 0xb0 pcmcia0 at cardslot0 ichpcib0 at pci0 dev 31 function 0 Intel 82801GBM LPC rev 0x02: PM disabled pciide0 at pci0 dev 31 function 1 Intel 82801GB IDE rev 0x02: DMA, channel 0 configured to
Re: IBM T60: ACPI suspend and resume working
Chris wrote: I'm trying to get ACPI suspend and resume working. Typing apm -z from my window manager's xterm just returns me back to the shell. Typing apmd and then apm -z tells me System will enter suspend mode momentarily. and then nothing happens. Following is my dmesg. Thanks for any help. AFAIK, ACPI suspend/resume et al is not supposed to work yet. /Alexander
ypldap
Dear list members, i am reading What's new for OpenBSD 4.4. It is stated about the initial import of ypldap(8). But, i cannot locate the ypldap daemon. Do you know where is it? Thanks a lot.
Re: ypldap
John Nietzsche ha scritto: Dear list members, i am reading What's new for OpenBSD 4.4. It is stated about the initial import of ypldap(8). But, i cannot locate the ypldap daemon. Do you know where is it? Thanks a lot. Search on the archives. http://marc.info/?t=12236616303r=1w=2
Re: 3.8 stable to 4.4 snapshot and the system is about 95% in interrupts with tcpdump on em(82541GI)
On Fri, Nov 14, 2008 at 1:01 AM, Stuart Henderson [EMAIL PROTECTED] wrote: please mail back to misc@ with your findings... Different kernels didn't make any visible difference. As didn't ACPI vs. APM. I could not get the system up with the MP kernel and ACPI enabled (see dmesg #1 attached). With APM it was no different from UP kernel and the box doesn't seem to have APIC. Perhaps the box is simple too weak to handle this amount of traffic, but further looking into the issue revealed a strange thing. When i run as root tcpdump -i em0 -s 2000 -w /dev/null the system spends 70%-80% in the interrupts and according to vmstat -i the rate of interrupts for em0 is *constantly growing*, that growth is strange: # vmstat -i interrupt total rate irq10/em0 14919 219 irq11/em1 10 irq14/pciide01117 16 irq15/pciide0 250 irq5/vr0 250 irq4/com0 1442 irq1/pckbc0 1422 irq0/clock 6866 100 irq8/rtc 8785 129 Total 32024 470 # vmstat -i interrupt total rate irq10/em0 28933 385 irq11/em1 10 irq14/pciide01118 14 irq15/pciide0 250 irq5/vr0 250 irq4/com0 1862 irq1/pckbc0 1421 irq0/clock 7533 100 irq8/rtc 9639 128 Total 47602 634 # vmstat -i interrupt total rate irq10/em0 32209 423 irq11/em1 10 irq14/pciide01118 14 irq15/pciide0 250 irq5/vr0 250 irq4/com0 2252 irq1/pckbc0 1421 irq0/clock 7691 101 irq8/rtc 9840 129 Total 51276 674 ... # vmstat -i interrupt total rate irq10/em0 91310 853 irq11/em1 10 irq14/pciide01124 10 irq15/pciide0 250 irq5/vr0 300 irq4/com0 5885 irq1/pckbc0 1421 irq0/clock 10723 100 irq8/rtc13722 128 Total 117665 1099 # vmstat -i interrupt total rate irq10/em0 99088 892 irq11/em1 10 irq14/pciide01124 10 irq15/pciide0 250 irq5/vr0 300 irq4/com0 6305 irq1/pckbc0 1421 irq0/clock 11142 100 irq8/rtc14258 128 Total 126440 1139 ... # vmstat -i interrupt total rate irq10/em0 138371 1048 irq11/em1 10 irq14/pciide011268 irq15/pciide0 250 irq5/vr0 320 irq4/com0 8256 irq1/pckbc0 1421 irq0/clock 13299 100 irq8/rtc17018 128 Total 170839 1294 # vmstat -i interrupt total rate irq10/em0 144395 1061 irq11/em1 10 irq14/pciide011268 irq15/pciide0 250 irq5/vr0 320 irq4/com0 8646 irq1/pckbc0 1421 irq0/clock 13626 100 irq8/rtc17437 128 Total 177648 1306 ... # date; vmstat -i Fri Nov 14 09:59:41 EET 2008 interrupt total rate irq10/em0 569013 1489 irq11/em1 20 irq14/pciide011282 irq15/pciide0 250 irq5/vr0 720 irq4/com021465 irq1/pckbc0 1420 irq0/clock 38246 100 irq8/rtc48949 128 Total 659723 1727 # #
Re: ypldap
On 2008-11-18, John Nietzsche [EMAIL PROTECTED] wrote: Dear list members, i am reading What's new for OpenBSD 4.4. It is stated about the initial import of ypldap(8). But, i cannot locate the ypldap daemon. Do you know where is it? Thanks a lot. /usr/src/usr.sbin/ypldap It was imported before 4.4, but not enabled in the build until more recently.
Re: Can't SSH into CARP'd system from the outside
On Thu, Nov 13, 2008 at 05:51:49PM -0800, Vivek Ayer wrote: Yay! I got ssh and http to work on the CARP interface. Thanks. However, the httpd redirect is not working just yet on the CARP interface for one of the computers. Does IP balancing mess up redirect? Well, that depends. IP balancing computes a commutative hash of the source and destination IP to decide which node accepts the packet. If you do a rdr, you modify the destination, thus the hash is different and the returning packet might end up on another node, which has no knowledge about the pf-NAT state. However, if you also NAT the outgoing packet to an address that belongs to one node only, you'll get the reply. That of course means that you won't have the client's original IP address for your apache access logs. IP balancing is no silver bullet. I designed as a simple solution to build a cluster of load balanced servers without the need of a separate load balancer. A pf pair with no nat/rdr is also easy to build. Translation is hard. Here's my current pf.conf: [...] # Basic CARP/pfsync pass rules pass on $carpdevs proto carp keep state this ^^^ is still wrong, btw. But your other rules seem to cover that traffic already anyway.
***5 MİLYON KİŞİYE REKLAMINIZI YAPIN : 50 YTL ***
Toplu mail gvnderimi hig ku~kusuz en g|gl| ve en etkili reklam yollar}ndan biridir. Toplu Mail Adresleri 50 YTL T|rkiyenin En B|y|k Mail Datas} 5 M]LYON ADET SEKTVREL 2008 G\NCEL MA]L ADRES] S]Z DE M\^TER] PORTFVY\N\Z\ GEN]^LETEREK \R\NLER]N]Z] ]NTERNET ORTAMINDA DAHA S\RATL] VE DAHA D\^\K B]R MAL]YETLE PAZARLAMAK ]STERSEN]Z MA]L ADRESLER]M]ZLE B]R AN VNCE TANI^MANIZI TAVS]YE EDER]Z. Fiyatlar}m}za KDV dahil depildir. L|tfen detayl} bilgi igin a~ap}daki telefonlardan bilgi al}n}z. TEL: 0 242 321 77 24 GSM: 0 541 321 77 24 AYRICA Lisansl} mail gvnderme program} : 100 YTL + K.D.V.
Problems with relayd
Hello,
I have big trouble with relayd on openBSD 4.4 to loadbalance 2 squid proxies :
* relayctl reload doesn't work. It just says command failed and nothing
appears in relayd logs (relayd launched with relayd -d)
I am testing right now, but when I will go in production to kill and restart
relayd won't be possible.
* even worse, I stopped squid on one machine, using relayctl show hosts the
machine is told to be down. But requests are still forwarded to it !
My relayd.conf :
node1=10.60.0.101
node2=10.60.0.102
squid_int=10.31.33.254
interval 5
log updates
prefork 10
timeout 1000
table squid { $node1 , $node2 }
http protocol http_proxy {
tcp { nodelay, sack, socket buffer 65536 , backlog 1000 }
}
relay squid {
listen on $squid_int port 3128
protocol http_proxy
forward to squid mode loadbalance check tcp
}
Is this a bug, or am I doing wrong ?
--
Cordialement,
Pierre BARDOU
CSIM - Bureau 012
Midi Pyrinies Informatique Hospitalihre
12 rue Michel Labrousse
BP93668
F-31036 Toulouse CEDEX 1
Til : 05 67 31 90 84
Fax : 05 34 61 51 00
Mail : [EMAIL PROTECTED]
Re: ami and bioctl questions
Dieter wrote: At work I've got a server with an LSI MegaRAID (dmesg below) that suddenly seems to be killing hard drives. Last Thursday I had one drive fail, and the system didn't begin rebuilding onto the hot spare until I rebooted. I would hope that the controller isn't killing drives. Me, too. Or the enclosure. Can we presume the system has clean power, temps are ok, no vibration, etc. ? Yes, all power is through an MGE Pulsar Evolution. The server is rack mounted, and sysctl reports all temps as normal. [EMAIL PROTECTED]:/home/jross $ sysctl -a | grep hw hw.sensors.ami0.drive0=degraded (sd0), WARNING hw.sensors.ami0.drive1=online (sd1), OK hw.sensors.ami0.drive2=online (sd2), OK hw.sensors.safte0.temp0=23.00 degC, OK hw.sensors.safte1.temp0=24.00 degC, OK hw.sensors.lm1.temp0=40.00 degC hw.sensors.lm1.temp1=29.00 degC hw.sensors.lm1.temp2=29.50 degC hw.sensors.lm1.fan0=6026 RPM hw.sensors.lm1.fan1=6026 RPM Hitachi's drive testing tool seems to be windows only, so are there any drive checking utilities that can check an individual drive when it's a part of a RAID1? Or is it safe to assume that if the drive fails in the RAID it is really dead. I'm trying to make sure I'm not seeing some kind of problem with the enclosure or the megaraid card before I start shipping drives back to Hitachi. Can you get the SMART data from the drives? Interpreting SMART data is another problem, but maybe you can find a clue there. Is it possible that the drives just took too long to read or write and the RAID marked them bad? Maybe remapping a bad sector takes too long... Maybe hook them to a different controller (no RAID) and do a simple test with dd over the entire drive, something like dd if=/dev/suspect_disk of=/dev/null bs=1m dd if=/dev/zero of=/dev/suspect_disk bs=1m and see if you get any errors from dd or in dmesg. Last night after all the users left I rebooted the server to get into the MegaRAID controller at boot. It couldn't see the brand new drive I just put into the safte0 enclosure so I couldn't make it a hot spare. I installed the now two drives that have failed into another server with an identical setup (one minor variation--it has two separate LSI MegaRAID cards instead of one card with two channels) and a completely empty safte enclosure and again the card could not see the drives at all. I'm thinking that means they really are dead. I have another chassis and a new SuperMicro motherboard with an onboard SCSI that I'll build up today. Then I should be able to get access to the individual drives without going through the LSI raid card and try to do those tests you suggest. The fact that the LSI card couldn't see that new drive (identical in size, but 15K instead of 10K) is disconcerting to say the least. The only comforting thought is that in this case sd0 contains the / , swap, /usr and so on partitions--all operating system and no database or web server partitions. I think I'll double up on the tape backups, just to be sure. Thanks for the suggestions. Jeff
Re: ami and bioctl questions
On Mon, Nov 17, 2008 at 01:44:27PM -0700, Jeff Ross wrote: Hi all, At work I've got a server with an LSI MegaRAID (dmesg below) that suddenly seems to be killing hard drives. Last Thursday I had one drive fail, and the system didn't begin rebuilding onto the hot spare until I rebooted. How did you create the hotspare? If you created it using an old version of ami there is a good chance that the hotspare creation didn't work right even though it shows up as a hotspare (weird firmware requirements when creating the hotspare; read the cvs logs for an explanation if you care). Today I lost another drive in the same safte0. I pulled another replacement drive off the shelf, swapped out the dead one, did a bioctl -H 0:9 sd0 to mark it as a hot spare but no rebuild has started yet. Note that 1:0 in safte1 was already marked as a hot spare, but this is a separate safte enclosure and I've never been sure if the hot spare would work across enclosures. I've always had a hot spare in each safte enclosure until this happened. As long as the hotspares are on the same controller it does not matter on what channel it is on. Again see my previous blurb about creating hotspares. Replacing the failed disk in the physical location with an appropriately sized disk will kick off the rebuild. In fact if you don't believe your disks are actually failed remove the failed one (make sure that you run some io to the logical disk when doing this) wait a few minutes and reinsert it. The ami card will then try to rebuild the raid set on that disk. This is obviously not recommended unless you know what you are doing! I'll say this even though someone might yell at me... Make sure you have appropriate cables and that the connectors are plugged in right. ami controllers are very sensitive to noise on the cables (all U320 gear really is). Don't use a shitty cable because that might lead to phantom failed drives (if a command doesn't complete within the required timeout the disk will be marked failed). Also if you have a cheap enclosure that only supports up to a certain speed you want to make sure that you throttle the channel to the appropriate speed. I have seen cheap enclosures pretend to run at U320 even though they really only could support U160. The results were,... odd. You can change this in the CTRL-M BIOS during POST. Here's the latest bioctl -i ami0 [EMAIL PROTECTED]:/home/jross $ sudo bioctl -v -i ami0 Volume Status Size Device ami0 0 Degraded 72999763968 sd0 RAID1 0 Failed73403465728 0:13.0 safte0 HITACHI HUS151473VL3800 S3C0 'J5VHVNPB' 1 Online73403465728 0:10.0 safte0 HITACHI HUS103073FL3800 SA1B 'V3W09L5A0050B499004B' ami0 1 Online72999763968 sd1 RAID1 0 Online73403465728 0:11.0 safte0 HITACHI HUS103073FL3800 SA1B 'V3W06MNA0050B4AD01D3' 1 Online73403465728 0:12.0 safte0 HITACHI HUS103073FL3800 SA1B 'V3W0A6VA0050B4A80C0C' ami0 2 Online72999763968 sd2 RAID1 0 Online73403465728 1:4.0 safte1 HITACHI HUS103073FL3800 SA1B 'V3VZV2JA0050B4AX04C2' 1 Online73403465728 1:1.0 safte1 HITACHI HUS103073FL3800 SA1B 'V3W0726A0050B49W01CB' ami0 3 Hot spare 73403465728 0:9.0 safte0 HITACHI HUS103073FL3800 SA1B 'V3W093EA0050B44V0578' ami0 4 Hot spare 73403465728 1:0.0 safte1 HITACHI HUS103073FL3800 SA1B 'V3W07PSA0050B4710207' Also interesting is that safte0 will not blink any of the drives, while safte 1 will. That is a safte problem. ami sends a generic blink command to the safte and it is up to it to honor it. [EMAIL PROTECTED]:/home/jross $ sudo bioctl -b 0:9 ami0 bioctl: BIOCBLINK: Operation not supported by device Questions, then: these drives are all Hitachi Ultrastars 10K300 from 2005. Has any one had any bad experiences with them? They are all still under warranty, and I don't suppose it's out of the question that 2 drives out of 8 would fail within 72 hours of each other, especially if the lot was bad. A bad cable can do this to you. I have seen drives fail in all kinds of different ways so this isn't as uncommon as you think either. Be cautious with those drives if you ascertain yourself that the rest of the hardware is in good shape. So far as I know, the SAFTE enclosures are identical. Why will one support blinking the drives and the other not? Ask you enclosure vendor. Should the ami be rebuilding the sd0 now that I've set a hot spare
Re: vpn with an iphone
jul wrote: Hello has someone setup a vpn tunnel between openbsd and an iphone ? it seems ipsec part is strictly limited to cisco ipsec with a user account/password so not good for us. Else there is pptp and l2tp but i'm not sure there is anything in base to do this. Ports seems to only have pptp as a client and i'm looking for server. any informations ? thanks a lot Cheers I apologize for the fairly off topic nature of this post, but I am assuming there may be other OpenBSD users out there trying to wrap their heads around what it would take to make an iPhone work with OpenBSD's default VPN method. The iPhone implements racoon to perform the IPsec portion of the iPhone L2TP. On a jailbroken phone, you can see an instance of the racoon process start / stop if you connect to / disconnect from an L2TP connection. You can also find the racoon executable in /usr/sbin if your iPhone is jailbroken. Unfortunately, racoon on the iPhone does not include setkey, which as far as I can tell is required to set up an IPsec tunnel with OpenBSD. There was a setkey floating around for firmware 1.x of the iPhone (see the post at http://forum.insanelymac.com/index.php?showtopic=98756 and find the download at http://pr0g.free.fr/iphone/setkey). I tried using this version of setkey on my 2.x firmware iPod Touch but, as is the case with most software compiled on 1.x, the program failed with an error. One would expect that it should be possible for an enterprising person to fetch ipsec-tools for Darwin (the latest as of writing is at http://www.opensource.apple.com/darwinsource/10.5.5/ipsec-34.0.2/) and compile a working setkey for the iPhone. Once done, creating an IPsec tunnel between an iPhone and OpenBSD should be nearly identical to creating such a tunnel using OS X or FreeBSD. Hopefully you can use this information. Breeno
Small patch for SIIG Cyber Serial 8S cards
Finally updated my console server that precipitated the original patch and found 4.4 didn't work with the card. Turns out when my patch got added, one digit was incorrect. Here's a patch to fix. --Kurt Index: pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1396 diff -u -r1.1396 pcidevs --- pcidevs 28 Jul 2008 16:53:18 - 1.1396 +++ pcidevs 18 Nov 2008 20:01:47 - @@ -3040,7 +3040,7 @@ product SIIG 20610x2061 I/O product SIIG 20620x2062 I/O product SIIG 20810x2081 I/O -product SIIG 20820x2081 I/O +product SIIG 20820x2082 I/O /* Solarflare products */ product SOLARFLARE FALCON_P0x0703 Falcon P
Re: Can't SSH into CARP'd system from the outside
I got that snippet from the pf book. What should I change it to? On Tue, Nov 18, 2008 at 4:32 AM, Marco Pfatschbacher [EMAIL PROTECTED] wrote: On Thu, Nov 13, 2008 at 05:51:49PM -0800, Vivek Ayer wrote: Yay! I got ssh and http to work on the CARP interface. Thanks. However, the httpd redirect is not working just yet on the CARP interface for one of the computers. Does IP balancing mess up redirect? Well, that depends. IP balancing computes a commutative hash of the source and destination IP to decide which node accepts the packet. If you do a rdr, you modify the destination, thus the hash is different and the returning packet might end up on another node, which has no knowledge about the pf-NAT state. However, if you also NAT the outgoing packet to an address that belongs to one node only, you'll get the reply. That of course means that you won't have the client's original IP address for your apache access logs. IP balancing is no silver bullet. I designed as a simple solution to build a cluster of load balanced servers without the need of a separate load balancer. A pf pair with no nat/rdr is also easy to build. Translation is hard. Here's my current pf.conf: [...] # Basic CARP/pfsync pass rules pass on $carpdevs proto carp keep state this ^^^ is still wrong, btw. But your other rules seem to cover that traffic already anyway.
Re: Can't SSH into CARP'd system from the outside
I may actually end up just turning off load balancing on the router for now and just leave it on the web servers. Then again, it would be nice if the router did some work since it'll be on all the time using all that electricity. Is there a clever cron script I could write to manually change the master on a day to day basis? Something using 'ifconfig carp0 down'. It would be nice if the routers took turns every day rather than every few seconds/minutes. On Tue, Nov 18, 2008 at 11:50 AM, Vivek Ayer [EMAIL PROTECTED] wrote: I got that snippet from the pf book. What should I change it to? On Tue, Nov 18, 2008 at 4:32 AM, Marco Pfatschbacher [EMAIL PROTECTED] wrote: On Thu, Nov 13, 2008 at 05:51:49PM -0800, Vivek Ayer wrote: Yay! I got ssh and http to work on the CARP interface. Thanks. However, the httpd redirect is not working just yet on the CARP interface for one of the computers. Does IP balancing mess up redirect? Well, that depends. IP balancing computes a commutative hash of the source and destination IP to decide which node accepts the packet. If you do a rdr, you modify the destination, thus the hash is different and the returning packet might end up on another node, which has no knowledge about the pf-NAT state. However, if you also NAT the outgoing packet to an address that belongs to one node only, you'll get the reply. That of course means that you won't have the client's original IP address for your apache access logs. IP balancing is no silver bullet. I designed as a simple solution to build a cluster of load balanced servers without the need of a separate load balancer. A pf pair with no nat/rdr is also easy to build. Translation is hard. Here's my current pf.conf: [...] # Basic CARP/pfsync pass rules pass on $carpdevs proto carp keep state this ^^^ is still wrong, btw. But your other rules seem to cover that traffic already anyway.
Re: ami and bioctl questions
Marco Peereboom wrote: On Mon, Nov 17, 2008 at 01:44:27PM -0700, Jeff Ross wrote: Hi all, At work I've got a server with an LSI MegaRAID (dmesg below) that suddenly seems to be killing hard drives. Last Thursday I had one drive fail, and the system didn't begin rebuilding onto the hot spare until I rebooted. How did you create the hotspare? If you created it using an old version of ami there is a good chance that the hotspare creation didn't work right even though it shows up as a hotspare (weird firmware requirements when creating the hotspare; read the cvs logs for an explanation if you care). I created it with bioctl, but my version is from a September 1 snapshot so it is before your fix. Today I lost another drive in the same safte0. I pulled another replacement drive off the shelf, swapped out the dead one, did a bioctl -H 0:9 sd0 to mark it as a hot spare but no rebuild has started yet. Note that 1:0 in safte1 was already marked as a hot spare, but this is a separate safte enclosure and I've never been sure if the hot spare would work across enclosures. I've always had a hot spare in each safte enclosure until this happened. As long as the hotspares are on the same controller it does not matter on what channel it is on. Again see my previous blurb about creating hotspares. Okay, that's good to know. I still have one hotspare that I will try to get the rebuild initiated on. Replacing the failed disk in the physical location with an appropriately sized disk will kick off the rebuild. In fact if you don't believe your disks are actually failed remove the failed one (make sure that you run some io to the logical disk when doing this) wait a few minutes and reinsert it. The ami card will then try to rebuild the raid set on that disk. This is obviously not recommended unless you know what you are doing! Unfortunately, I don't count myself in the camp of knowing what I'm doing :-) but I'm learning more as I go. Probably I will have to try this tonight after everyone else leaves. I'll say this even though someone might yell at me... Make sure you have appropriate cables and that the connectors are plugged in right. ami controllers are very sensitive to noise on the cables (all U320 gear really is). Don't use a shitty cable because that might lead to phantom failed drives (if a command doesn't complete within the required timeout the disk will be marked failed). The server ran flawlessly for 2 years now, and I'll bet it's been a year since I've even slid it forward enough in the rack to get the cover off. Do cables go bad with use? Also if you have a cheap enclosure that only supports up to a certain speed you want to make sure that you throttle the channel to the appropriate speed. I have seen cheap enclosures pretend to run at U320 even though they really only could support U160. The results were,... odd. You can change this in the CTRL-M BIOS during POST. These are SuperMicro GEM enclosures that are rated for U320 and they weren't cheap in my book but then that's a relative thing. Here's the latest bioctl -i ami0 [EMAIL PROTECTED]:/home/jross $ sudo bioctl -v -i ami0 Volume Status Size Device ami0 0 Degraded 72999763968 sd0 RAID1 0 Failed73403465728 0:13.0 safte0 HITACHI HUS151473VL3800 S3C0 'J5VHVNPB' 1 Online73403465728 0:10.0 safte0 HITACHI HUS103073FL3800 SA1B 'V3W09L5A0050B499004B' ami0 1 Online72999763968 sd1 RAID1 0 Online73403465728 0:11.0 safte0 HITACHI HUS103073FL3800 SA1B 'V3W06MNA0050B4AD01D3' 1 Online73403465728 0:12.0 safte0 HITACHI HUS103073FL3800 SA1B 'V3W0A6VA0050B4A80C0C' ami0 2 Online72999763968 sd2 RAID1 0 Online73403465728 1:4.0 safte1 HITACHI HUS103073FL3800 SA1B 'V3VZV2JA0050B4AX04C2' 1 Online73403465728 1:1.0 safte1 HITACHI HUS103073FL3800 SA1B 'V3W0726A0050B49W01CB' ami0 3 Hot spare 73403465728 0:9.0 safte0 HITACHI HUS103073FL3800 SA1B 'V3W093EA0050B44V0578' ami0 4 Hot spare 73403465728 1:0.0 safte1 HITACHI HUS103073FL3800 SA1B 'V3W07PSA0050B4710207' Also interesting is that safte0 will not blink any of the drives, while safte 1 will. That is a safte problem. ami sends a generic blink command to the safte and it is up to it to honor it. I may try to replace the safte0 enclosure this weekend then. [EMAIL PROTECTED]:/home/jross $ sudo bioctl -b 0:9 ami0 bioctl: BIOCBLINK: Operation not supported by device Questions,
Re: 4.4 Samba write performance
Answers to your questions are inline /w the question 2008/11/18 tico [EMAIL PROTECTED]: 1. Why is this sent to the ports@ mailing list ? I've lurked the list for a long time - since around 2.8. I've asked the odd question here and/or there, and got flamed once when I asked about a question in misc about a port and was subsequently corrected. Since the main topic is about using samba it belongs in ports. See ports general interest list comment @ http://www.openbsd.org/mail.html 2. What performance comparison is showing you that the write throughput that you *are* achieving is bad? The beginning of email before I *tweaked* (which I didn't want to do) 170meg copy was really slow. So I tossed in the aforementioned crap based on an internet search that didn't really have a satisfactory discussion on the subject - just things to try. I have much nicer systems on nicer 100Mbit managed switches that individual Windows clients are not able to drive at higher than 9MB/sec ~= 72Mbits. If you're ranging from 4-12MBytes/sec, those are good real-world numbers. One of these days I should learn how to apply the math I learned. I still am not good at math problems like this one. Thus I still have no idea what I should be expecting - and I guess that was the real problem. Last time I had my little home network file storage served by OpenBSD (by nearly the same hardware, by the way) it just *felt* faster. My previous install still does feel faster. This post is a result of that. 3. If you want to test out your problem, why haven't you tested out the network throughput capability of your system/network, separately from the disk I/O capability? /dev/null and /dev/zero exist. use them. Didn't think of it. But then didn't suspect it to begin with. See the rest in answer the answer to #4. Certainly something to try. 4. Why are you trying to tweak the TCP stack of your system, if you don't know what each piece does, whether or not it's a bottleneck, and what the trade-offs are from adjusting it? There is no kern.system.go.faster=true option for a reason. I know. Hence this conversation. I've got no peer in all of the technologists that I know to learn from @ the moment. Premature optimization is the root of all evil -- Knuth Are you sure that PCI cards sharing the same IRQ is a performance problem? No, but I wanted to point it out - because being more of a hardware guy I've seen the cause of problems from it before. Though much less prevalent these days. I have systems that serve 100's of megs of data where multiple NICs are sharing the same IRQ. Don't drink the kool-aid that you find on random forums. Only attempt to optimize what you can establish is *actually* a problem. Do you want to see one of my client's fileserver systems that serves data faster than the Windows clients can eat it? You bet, and thanks for including it! --- from a stock smb.conf: [global] workgroup = BHD server string = Samba Server passdb backend = tdbsam log file = /var/log/smbd.%m max log size = 50 os level = 33 preferred master = Yes domain master = Yes dns proxy = No wins support = Yes hosts allow = 192.168.1., 192.168.0., 127. -- # uname -m -r -v 4.4 GENERIC#1915 amd64 # grep -v ^# /etc/sysctl.conf net.inet.ip.forwarding=1# 1=Permit forwarding (routing) of IPv4 packets # em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:30:48:9a:17:34 description: internal net (VLAN100 untagged) media: Ethernet autoselect (100baseTX full-duplex) status: active inet6 fe80::230:48ff:fe9a:1734%em0 prefixlen 64 scopeid 0x1 inet 192.168.0.252 netmask 0xff00 broadcast 192.168.0.255 I'm running a single RAID1 volume (should be slower than your single disk) Actually I disagree. You've got hardware RAID (a host processor to handle and optimize the duplication of data without bothering the rest of the computer) /w a large cache. I've got an add-in 32bit pci card 32M cache on the drive. on a pair of SATA drives on an Areca controller: arc0 at pci2 dev 14 function 0 Areca ARC-1210 rev 0x00: irq 5 arc0: 4 ports, 256MB SDRAM, firmware V1.43 2007-4-17 scsibus0 at arc0: 16 targets, initiator 16 sd0 at scsibus0 targ 0 lun 0: Areca, firstRAID1volume, R001 SCSI3 0/direct fix ed sd0: 715255MB, 512 bytes/sec, 1464843264 sec total no exotic filesystem mounts either: /dev/sd0j on /home/art type ffs (local, noatime, nodev, nosuid, softdep) /dev/sd0e on /home type ffs (local, noatime, nodev, nosuid, softdep) /dev/sd0k on /home/sandbox type ffs (local, noatime, nodev, nosuid, softdep) If it ain't broke, don't fix^H^H^H break it. ::yawn:: -Tico !- snip original message -!
Re: ami and bioctl questions
I created it with bioctl, but my version is from a September 1 snapshot so it is before your fix. There is a good chance that the hotspare does not work prior to that fix. I'd say this explains what you see. The server ran flawlessly for 2 years now, and I'll bet it's been a year since I've even slid it forward enough in the rack to get the cover off. Do cables go bad with use? No but they might have been dislodged when you moved the server. I may try to replace the safte0 enclosure this weekend then. It could be that it is simply hung (GEM chips tend to do that). Power cycle the whole thing to see what happens. If the GEM is hung there is a chance that the SCSI bus is hung too. This can easily lead to the issues you have been seeing (I have seen this in the past on other enclosures with a GEM chip). So the last combination combination I tried is the correct one? It still fails here: [EMAIL PROTECTED]:/usr/src $ sudo bioctl -q sd0 bioctl: DIOCINQ: Invalid argument I should have said not raided disks. I guess I could add that functionality to RAID disks as well even though it is mostly bogus it is nice if it all works the same. Thanks for your input and expertise, Marco. If you get a moment, I posted a follow-up as a reply to Dieter's response. There are more anomalies afoot I fear, especially with drives just not showing up, even in the crtl-m bios. If drives are missing and other weird things are happening you can assure yourself of bad hardware somewhere in the chain. Again check cables (maybe they were under tension and something snapped when you moved it), drives, the enclosure itself etc. A bad device can hang the bus and only limited IO will make it through (if any); this causes all kinds of mayhem on SCSI busses and is the primary reason why SCSI went SAS (point to point instead of bus). Figuring this out can be tedious and painful so be prepared to spend enough time on it.
Problems starting iwi
Hi all, It has been a long time since I haven't use the iwi device on my laptop (IBM T43). Before, all I had to do was ifconfig iwi0 up for the antenna light to blink. Now I can't find the way to start it. ifconfig iwi0 chan don't find a thing and of course dhclient iwi0 tell me no link. I really don't know what's going on. Any ideas ? Cheers, Cedric OpenBSD 4.4-current (GENERIC) #27: Wed Nov 12 22:22:46 CET 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) M processor 1.86GHz (GenuineIntel 686-class) 1.87 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF,EST,TM2 real mem = 1005023232 (958MB) avail mem = 963149824 (918MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 08/21/06, BIOS32 rev. 0 @ 0xfd760, SMBIOS rev. 2.33 @ 0xe0010 (64 entries) bios0: vendor IBM version 1YET65WW (1.29 ) date 08/21/2006 bios0: IBM 2668WEV apm0 at bios0: Power Management spec V1.2 apm0: battery life expectancy 100% apm0: AC on, battery charge high acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xfd6f0/0x910 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdeb0/256 (14 entries) pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82371FB ISA rev 0x00) pcibios0: PCI bus #12 is the last bus bios0: ROM list: 0xc/0x1 0xd/0x1600 0xd1800/0x1000 0xdc000/0x4000! 0xe/0x1 cpu0 at mainbus0: (uniprocessor) cpu0: Enhanced SpeedStep 1867 MHz (1308 mV): speeds: 1867, 1600, 1333, 1067, 800 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82915GM Host rev 0x03 ppb0 at pci0 dev 1 function 0 Intel 82915GM PCIE rev 0x03: irq 11 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 ATI Radeon Mobility M300 M22 rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) radeondrm0 at vga1 ppb1 at pci0 dev 28 function 0 Intel 82801FB PCIE rev 0x03: irq 11 pci2 at ppb1 bus 2 bge0 at pci2 dev 0 function 0 Broadcom BCM5751M rev 0x11, BCM5750 B1 (0x4101): irq 11, address 00:11:25:a8:76:2e brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 ppb2 at pci0 dev 28 function 2 Intel 82801FB PCIE rev 0x03: irq 11 pci3 at ppb2 bus 3 uhci0 at pci0 dev 29 function 0 Intel 82801FB USB rev 0x03: irq 11 uhci1 at pci0 dev 29 function 1 Intel 82801FB USB rev 0x03: irq 11 uhci2 at pci0 dev 29 function 2 Intel 82801FB USB rev 0x03: irq 11 uhci3 at pci0 dev 29 function 3 Intel 82801FB USB rev 0x03: irq 11 ehci0 at pci0 dev 29 function 7 Intel 82801FB USB rev 0x03: irq 11 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb3 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xd3 pci4 at ppb3 bus 11 cbb0 at pci4 dev 0 function 0 Ricoh 5C476 CardBus rev 0x8d: irq 11 iwi0 at pci4 dev 2 function 0 Intel PRO/Wireless 2200BG rev 0x05: irq 11, address 00:12:f0:ac:4b:30 cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 12 device 0 cacheline 0x0, lattimer 0xb0 pcmcia0 at cardslot0 auich0 at pci0 dev 30 function 2 Intel 82801FB AC97 rev 0x03: irq 11, ICH6 AC97 ac97: codec id 0x41445374 (Analog Devices AD1981B) ac97: codec features headphone, 20 bit DAC, No 3D Stereo audio0 at auich0 Intel 82801FB Modem rev 0x03 at pci0 dev 30 function 3 not configured ichpcib0 at pci0 dev 31 function 0 Intel 82801FBM LPC rev 0x03: PM disabled pciide0 at pci0 dev 31 function 2 Intel 82801FBM SATA rev 0x03: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: HTS541080G9AT00 wd0: 16-sector PIO, LBA, 76319MB, 156301488 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets, initiator 7 cd0 at scsibus0 targ 0 lun 0: MATSHITA, DVD-RAM UJ-822S, 1.61 ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 ichiic0 at pci0 dev 31 function 3 Intel 82801FB SMBus rev 0x03: irq 11 iic0 at ichiic0 usb1 at uhci0: USB revision 1.0 uhub1 at usb1 Intel UHCI root hub rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1 usb3 at uhci2: USB revision 1.0 uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1 usb4 at uhci3: USB revision 1.0 uhub4 at usb4 Intel UHCI root hub rev 1.00/1.00 addr 1 isa0 at ichpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 lpt2 at isa0 port 0x3bc/4: polled aps0 at isa0 port 0x1600/31 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 biomask efe5
Re: Problems starting iwi
Before, all I had to do was ifconfig iwi0 up for the antenna light to blink. Now I can't find the way to start it. ifconfig iwi0 chan don't find a thing and of course dhclient iwi0 tell me no link. ... iwi0: fatal firmware error Did you save or reinstall the firmware files when you upgraded?
Problems starting iwi
On Tue, Nov 18, 2008 at 11:28 PM, John Bartoszewski [EMAIL PROTECTED] wrote: Before, all I had to do was ifconfig iwi0 up for the antenna light to blink. Now I can't find the way to start it. ifconfig iwi0 chan don't find a thing and of course dhclient iwi0 tell me no link. ... iwi0: fatal firmware error Did you save or reinstall the firmware files when you upgraded? Hi John, When I upgraded to -current, I kept the firmware downloaded before on damien's website (3.0) : [EMAIL PROTECTED]: ~ $ pkg_info | grep iwi iwi-firmware-3.0Firmware binary image for iwi driver Cedric.
Re: Can't SSH into CARP'd system from the outside
Vivek Ayer [EMAIL PROTECTED] writes: I got that snippet from the pf book. What should I change it to? actually The Book of PF leaves the definition of the carpdevs macro as an excercise to the reader. The main reason to mention it at all is to alert the reader that carp traffic needs to pass. In some configurations, a separate rule for that traffic is not needed. - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Problems starting iwi
Hi John, When I upgraded to -current, I kept the firmware downloaded before on damien's website (3.0) : [EMAIL PROTECTED]: ~ $ pkg_info | grep iwi iwi-firmware-3.0Firmware binary image for iwi driver Cedric. You may want to upgrade to the 3.0p0 firmware now available from Damien's site. -- Joe Gidi [EMAIL PROTECTED] You cannot buy skill. -- Ross Seyfried
Re: Problems starting iwi
On Tuesday 18 November 2008, Cedric Brisseau wrote: iwi0: fatal firmware error I think there was an error loading the firmware. Without loaded firmware the device is unusable. Sven
Re: Problems starting iwi
On Wed, Nov 19, 2008 at 12:30 AM, Joe Gidi [EMAIL PROTECTED] wrote: Hi John, When I upgraded to -current, I kept the firmware downloaded before on damien's website (3.0) : [EMAIL PROTECTED]: ~ $ pkg_info | grep iwi iwi-firmware-3.0Firmware binary image for iwi driver Cedric. You may want to upgrade to the 3.0p0 firmware now available from Damien's site. I checked and the 3.0p0 contains exactly the same firmware files (same MD5). The only difference between the two is the '@ignore' construct in the +CONTENTS file.
conversation with su failed in KDE
Hello, I'm working on my laptop with OpenBSD 4.4 and am quite pleased with it thus far. However, I am having trouble with KDE, specifically accessing administrator mode in many of the Control Center dialogs. It prompts me for my password, but no matter whether I type the root password or the password for my normal user account I get the error message conversation with su failed, and it won't let me do such things as add printers, change the screen resolution, etc. I have searched high and low for a solution to this before consulting the list; is there anyone who has encountered similar issues and have successfully resolved this issue? I can't be the only OpenBSD user using KDE who has run into this problem. ;-) - Mark Beihoffer http://mark.beihoffer.com
Re: conversation with su failed in KDE
On Tue, 18 Nov 2008, Mark Beihoffer wrote: Hello, I'm working on my laptop with OpenBSD 4.4 and am quite pleased with it thus far. However, I am having trouble with KDE, specifically accessing administrator mode in many of the Control Center dialogs. It prompts me for my password, but no matter whether I type the root password or the password for my normal user account I get the error message conversation with su failed, and it won't let me do such things as add printers, change the screen resolution, etc. I have searched high and low for a solution to this before consulting the list; is there anyone who has encountered similar issues and have successfully resolved this issue? I can't be the only OpenBSD user using KDE who has run into this problem. ;-) What is the content of: /usr/local/share/config/kdesurc -- Antoine
Re: ami and bioctl questions
Marco Peereboom wrote: I created it with bioctl, but my version is from a September 1 snapshot so it is before your fix. There is a good chance that the hotspare does not work prior to that fix. I'd say this explains what you see. The server ran flawlessly for 2 years now, and I'll bet it's been a year since I've even slid it forward enough in the rack to get the cover off. Do cables go bad with use? No but they might have been dislodged when you moved the server. I may try to replace the safte0 enclosure this weekend then. It could be that it is simply hung (GEM chips tend to do that). Power cycle the whole thing to see what happens. If the GEM is hung there is a chance that the SCSI bus is hung too. This can easily lead to the issues you have been seeing (I have seen this in the past on other enclosures with a GEM chip). I power cycled the server after my users went home, checked the cables, and after about a hour's worth of hair-pulling nvram/disk configuration mismatches I finally got the system back up with sd0 in degraded mode and the other two optimal. Brought the system up to the most recent snapshot and did a bioctl -H 1:0 sd0 and the rebuild kicked off immediately. [EMAIL PROTECTED]:/home/jross $ sudo bioctl -v -i ami0 Volume Status Size Device ami0 0 Degraded 72999763968 sd0 RAID1 0 Failed 0 0:9.0 safte0 'unknown serial' 1 Online73403465728 0:10.0 safte0 HITACHI HUS103073FL3800 SA1B 'V3W09L5A0050B499004B' ami0 1 Online72999763968 sd1 RAID1 0 Online73403465728 0:11.0 safte0 HITACHI HUS103073FL3800 SA1B 'V3W06MNA0050B4AD01D3' 1 Online73403465728 0:12.0 safte0 HITACHI HUS103073FL3800 SA1B 'V3W0A6VA0050B4A80C0C' ami0 2 Online72999763968 sd2 RAID1 0 Online73403465728 1:4.0 safte1 HITACHI HUS103073FL3800 SA1B 'V3VZV2JA0050B4AX04C2' 1 Online73403465728 1:1.0 safte1 HITACHI HUS103073FL3800 SA1B 'V3W0726A0050B49W01CB' ami0 3 Unused73407899648 0:13.0 safte0 HITACHI HUS103073FL3800 SA1B 'V3W093EA0050B44V0578' ami0 4 Unused73407899648 1:0.0 safte1 HITACHI HUS103073FL3800 SA1B 'V3W07PSA0050B4710207' [EMAIL PROTECTED]:/home/jross $ sudo bioctl -H 1:0 sd0 [EMAIL PROTECTED]:/home/jross $ sudo bioctl -v -i ami0 Volume Status Size Device ami0 0 Rebuild 72999763968 sd0 RAID1 0% done 0 Rebuild 73403465728 1:0.0 safte1 HITACHI HUS103073FL3800 SA1B 'V3W07PSA0050B4710207' 1 Online73403465728 0:10.0 safte0 HITACHI HUS103073FL3800 SA1B 'V3W09L5A0050B499004B' ami0 1 Online72999763968 sd1 RAID1 0 Online73403465728 0:11.0 safte0 HITACHI HUS103073FL3800 SA1B 'V3W06MNA0050B4AD01D3' 1 Online73403465728 0:12.0 safte0 HITACHI HUS103073FL3800 SA1B 'V3W0A6VA0050B4A80C0C' ami0 2 Online72999763968 sd2 RAID1 0 Online73403465728 1:4.0 safte1 HITACHI HUS103073FL3800 SA1B 'V3VZV2JA0050B4AX04C2' 1 Online73403465728 1:1.0 safte1 HITACHI HUS103073FL3800 SA1B 'V3W0726A0050B49W01CB' ami0 3 Unused73407899648 0:13.0 safte0 HITACHI HUS103073FL3800 SA1B 'V3W093EA0050B44V0578' ami0 4 Unused73407899648 1:0.0 safte1 HITACHI HUS103073FL3800 SA1B 'V3W07PSA0050B4710207' So it looks like 0:9 is still a bad disk--I'll try to check that out tomorrow in the new server. The cables were all tight connections but I wonder about the quality. They are both loose bundled round cables with 5 connectors but I'm only using one for the safte. They were what I had at the time, but I'd sure take an suggestions for a good vendor and to get some really good cables. Thanks again, Jeff
Re: ami and bioctl questions
Hitachi's drive testing tool seems to be windows only, so are there any drive checking utilities that can check an individual drive when it's a part of a RAID1? Or is it safe to assume that if the drive fails in the RAID it is really dead. I'm trying to make sure I'm not seeing some kind of problem with the enclosure or the megaraid card before I start shipping drives back to Hitachi. Can you get the SMART data from the drives? Interpreting SMART data is another problem, but maybe you can find a clue there. Whoops, I had SATA on the brain, sorry about that. Last night after all the users left I rebooted the server to get into the MegaRAID controller at boot. It couldn't see the brand new drive I just put into the safte0 enclosure so I couldn't make it a hot spare. Seems unlikely that a brand new drive is bad as well as two existing drives. I installed the now two drives that have failed into another server with an identical setup (one minor variation--it has two separate LSI MegaRAID cards instead of one card with two channels) and a completely empty safte enclosure and again the card could not see the drives at all. I'm thinking that means they really are dead. Possible, but it seems unlikely. The fact that the LSI card couldn't see that new drive (identical in size, but 15K instead of 10K) is disconcerting to say the least. It makes me think that your drives are probably not the problem. See Marco's response about how it may not work using an old version of ami, and ami controllers are very sensitive to noise on the cables (all U320 gear really is). Are the cables routed near something electrically noisy? Could there be a problem with the termination? Has anything changed recently? The server ran flawlessly for 2 years now, and I'll bet it's been a year since I've even slid it forward enough in the rack to get the cover off. Do cables go bad with use? A cable is unlikely to go bad just sitting there unless it is getting abused somehow. Cables that are outdoors can go bad due to rain, UV, critters chewing on them, etc. Cables running across the floor can go bad from being stepped on, carts run over them, etc. Cables next to something sharp and getting vibrated could go bad. Cables that get plugged/unplugged a lot can wear out the connector, or wires can break from being flexed too many times. Hard to believe, but some connectors are only rated for three, yes 3, connect/disconnect cycles. One would expect SCSI gear to be rated for a lot more than that. I would expect SCSI connectors to be gold plated, so corrosion shouldn't be a problem. I've seen connectors lose their springiness and fail to make good contact. (One case where it does go bad just sitting there.) I'm sure there are more possible failure modes, but you get the idea. These are SuperMicro GEM enclosures that are rated for U320 and they weren't cheap in my book but then that's a relative thing. SCSI is never inexpensive. Sometimes I spell it $C$I. I'm not familiar with SuperMicro GEM enclosures, perhaps someone who is could comment on the quality level.
