Re: support new
On Sat, Apr 27, 2019 at 12:38:09PM +0200, Rolf wrote: 0 C Belgium P Oost-Vlaanderen T Dendermonde Z 9200 O MetaData I Rolf A Oliestraat 50 M sa...@metadata.be U https://metadata.be/ B +32 477 29 76 04 X N/A N Network consulting, installation and maintenance. Hosting services. Can I ask again to take a look at this?
support new
0 C Belgium P Oost-Vlaanderen T Dendermonde Z 9200 O MetaData I Rolf A Oliestraat 50 M sa...@metadata.be U https://metadata.be/ B +32 477 29 76 04 X N/A N Network consulting, installation and maintenance. Hosting services.
support new
0 C Belgium P Oost-Vlaanderen T Dendermonde Z 9200 O MetaData I Rolf A Oliestraat 50 M sa...@metadata.be U https://www.metadata.be/ B +32 (0)4 7729 76 04 N Network consulting, installation and maintenance is our core business. We focus on security and stability in implementing customers' wishes. We prefer free and standard compliant software. We deliver desktop, server and cloud services for any size enterprise.
Re: bridge fails to broadcast ARP from gif tunnel
Hi Goda, On Tue, Dec 1, 2015 at 10:07 AM, Kazuya GODA wrote: > It seems to bridge doesn't forward broadcast/multicast frames from gif. > This pathc will fix this problem, so would you try it? Indeed, your patch fixes the problem! Excellent, thank you very much. Now, I will go on and try IPsec with the same bridge test setup... :-) Will you merge the fix into -current? Thanks again, Rolf
Re: bridge fails to broadcast ARP from gif tunnel
Looking at the source in sys/netinet/ip_ether.c of void etherip_decap(struct mbuf *, int); which calls etherip_getgif(struct mbuf *m) first, and then clears these flags of the _inner_ Ethernet header: ... /* Reset the flags based on the inner packet */ m->m_flags &= ~(M_BCAST|M_MCAST|M_AUTH|M_CONF|M_PROTO1); Why? I can not yet understand this (false?) symmetry to what gif_encap() does to the outer Ethernet header which gif_output() calls in sys/net/if_gif.c . Could that be the cause of my problem where Ethernet frames that come out of the gif tunnel and are EtherIP decapsulated are actually not forwarded by the other members of the bridge because the M_MCAST bit got cleared, instead being left untouched on decapsulation? Setting up a build host with current right now to find out...
Re: bridge fails to broadcast ARP from gif tunnel
After adding static ARP entries 'arp -s 172.16.1.5 ' to the ARP tables on each end HostA and HostB respectively, ping (and tcpbench) work fine end to end through the gif tunnels, from both sides. Thus my problem appears to be limited to ARP Requests resp. their Ethernet broadcasts not being forwarded properly by the bridges if they come into the bridge via an EtherIP tunnel from a gif interface...
bridge fails to broadcast ARP from gif tunnel
Using the simple Layer-2 bridge setup below, an ICMP Ping 172.17.1.5 from HostA does not get to HostB while using EtherIP encapsulation with gif(4) at its tunnel end points. The Ping's initial Ethernet broadcasts with the ARP Requests make it through the gif tunnel to BridgeB, to both its bridge0 and vio2 interfaces (check with tcpdump, tshark). However, vio2 never re-broadcasts those ARP Requests on the wire to HostB!? E.g. the physical egress interface vio2, which is member of a bridge(4) on BridgeB, receives the ARP Requests, but it fails re-broadcast them to HostB so that Host could answer with ARP Reponses. Also, BridgeB does not learn the source MAC from HostA (and of course it can not learn the MAC of HostB, because ARP Requests never get there). However, pinging the (numbered) vio2 on BridgeB succeeds (Ping 172.17.1.2 from HostA), e.g. the gif tunnel is OK. Also, HostA can ping HostB after removal of the gif tunnel, e.g. after deleting gif0 from bridge0 on both BridgeA and BridgeB, and adding vio1 to them instead. Testing conditions: - default installs of OpenBSD i386 snapshot from yesterday - pf is disabled - no L2 filter rules on the bridge member interfaces - set sysctl net.inet.etherip.allow=1 to enable EtherIP on gif() - the observation is the same on both VirtualBox with vio() interfaces, as well as on a real hardware with APU2 that have em() interfaces. Currently, experimenting with pf enabled on BridgeB, I found that ARP Requests apparently do not generate state with a very basic rule-set, such as 'pass log all'. What did I miss? Or, is there "just a bug" in the gif/bridge combo that is haunting me? Would it be worthwhile to try with -stable or an older version of OpenBSD? Years ago, I had such a setup working with 4.3, and I can make configuration files available (although they are very minimal, mostly running default install) ... Thanks for any hints and suggestions! Rolf *HostA* vio1 172.16.0.5/22 | v vio2 172.16.0.2/22 *BridgeA* bridge0 add vio2 add gif0 gif0 tunnel 10.10.1.2 10.10.1.3 vio1 10.10.1.2/24 | v vio1 10.10.1.3/24 gif0 tunnel 10.10.1.3 10.10.1.2 bridge0 add vio2 add gif0 *BridgeB* vio2 172.16.1.2/22 | v vio1 172.16.1.5/22 *HostB*
Re: Install from snapshot unable boot
On Fri, Nov 27, 2015 at 9:01 AM, Antoine Jacoutot wrote: > Yeah, that's because of pledge(2): > installboot(19095): syscall 54 "ioctl" Thank for your confirmation. I did not spot the error message above, but saw a commit from Theo last night related to installboot. So I thought this might be connected, and maybe relevant feedback.
Install from snapshot unable boot
The current snapshot fails to install from .iso at the very last step at writing the boot info to disk on VirtualBox. http://mirror.switch.ch/ftp/pub/OpenBSD/snapshots/i386/BUILDINFO Build date: 1448569476 - Thu Nov 26 20:24:36 UTC 2015 Using "the same procedure", install from an older i386 snapshot from 5 Nov 2015, followed by an update to the current snapshot using bsd.rd, works as usual.
pair(4) + pf(4) and ipsec(4)
Hi, On a rainy/snowy Sunday, I am trying to "renovate" an ancient but working Layer-2 Ethernet bridge over IPsec over wireless LAN setup that I had implemented using isakmpd (IKEv1) in OpenBSD 4.3 on WRAP boards from PC Engines, and bring it up to date with iked (IKEv2) using latest crypto transforms in OpenBSD -current on two APU2 boards :-) With his OK in [1], Reyk briefly described of his test scenario(s): "tested with pair(4) ... ipsec on pair(4) ... routed ipsec on pair(4) ... (pair0 -> ipsec -> pair1 -> $ext_if) ... bridge/pair stp ..." Do I interpret this correctly as representing (at least) five different use cases that are separated by ellipses '...'? Can ipsec() use pair() directly without going through gif(4) and bridge(4) (with Link2 set), e.g. is only the last case above involving bridge()? (Probably unlikely, as pair(4) like vether(4) are always members of bridges according to ther man pages.) What is the difference between the 2nd and 3rd use cases, e.g. Layer-2 bridging vs. Layer-3 routing over IPsec tunnels? Would you mind to share maybe some (fragments of) configurations that illustrate those use cases? Thanks, Rolf [1] Re: pair(4) + pf(4): reset all state on "reinjected" packets http://permalink.gmane.org/gmane.os.openbsd.tech/45411
carp(4) requires carpdev in OpenBSD 5.7
After upgrading a firewall cluster from 5.6 to 5.7, I observed that carpX interfaces failed to come up with their settings. A manual start 'sh /etc/netstart carpX' ran without errors, although carpX still did not get its settings from hostname.carpX. However, 'ifconfig carpX 10.0.8.1 vhid 108' failed: ifconfig: SIOCAIFADDR: Invalid argument http://www.openbsd.org/57.html revealed that carp(4) now needs to be configured with an explicit carpdev parent interface (as from 5.7). Thus adding 'carpdev vlanX' to the ifconfig or hostname.carpX solved my problem :-) Apparently, I had been mentioned in a previous revision of "following -current", too. May I suggest to mention it in the "Other changes" section of the Upgrade 5.6->5.7 document? Also, it might be helpful to add carpdev to the examples, which is now mandatory, in the carp(4) man pages. Thanks, Rolf
Re: MPLS VPN on OpenBSD
Have you noticed the paper which Claudio Jeker had presented at EuroBSDCon 2011? http://2011.eurobsdcon.org/papers/jeker/MPLS.pdf Althought the talk is listed at http://www.openbsd.org/events.html it is missing at http://www.openbsd.org/papers/
NAT64 sample config
Maybe you are interested in giving NAT64 a try which has been committed to the tree a few weeks ago. In my first test I found it works great. Thanks to the developers for their hard work! Eventually, the following sample config saves you some time while the man pages are in the works, although looking through the commit logs, source code, and conference presentations is always educational. Note that NAT64 is not in 5.0-release, but you need a snapshot which is not older than three weeks or so. The following line in /etc/pf.conf is all which is required to setup a "stateful NAT64" on an OpenBSD box which has one interface in an IPv6 segment, and another interface in an IPv4 segment (private LAN, or even the Internet): pass in log on vic1 inet6 from any to 64:ff9b::/96 \ af-to inet from 192.168.98.74 For my test, I installed OpenBSD i386 snapshot from 3 Nov 11 on ESXi 4.1u1. vic1 is the "inside" interface on a vSwitch that accomodate IPv6 hosts exclusively. The "outside" interface vic0 is in IPv4-only segment and has the IP address 192.168.98.74. The above pf rule translates all ingress IPv6 traffic on vic1, which wants to go to destinations with the special prefix 64:ff9b::/96, to IPv4 with the source (NAT64) address of the outer interface vic0 ingress. pf implicitly takes the IPv4 destination (NAT64) from the lower 32 bits of the IPv6 destination address. This rule creates state, therefore return traffic is translated implicitly, e.g. you should not add any rule for return traffic. I derived this rule from Claudio@'s example in the commit log, which translates from v4 to v6, and where Claudio mentioned that the trailing "to" is optional for NAT64 http://marc.info/?l=openbsd-cvs&m=131853093528864 Besides testing a separate commercial virtual IPAM/DNS appliance from Infoblox to provide DNS64 Application Level Gateway functionality, I have also successfully tested the "totd" DNS proxy which provides similar DNS64 functionality (less DNS resolver and caching). OpenBSD has a package for "totd", so just do "pkg_add totd". As time allows, I might move the virtual NAT64 and DNS64 gateway over to an ALIX board. This portable demonstrator shall eventually gateway IPv6-only clients on its wireless LAN IPv6-only interface to IPv4-only Internet over 3G/UMTS - just for a fun alternative to v6 over v4 tunnels... Regards, Rolf A) /etc/totd.conf : interfaces vic1 #port 53 forwarder 192.168.99.26 prefix 64:ff9b:: retry 300 B) DNS lookup for resource records of google.com using the DNS64 proxy yields answers with the 64:ff9b::/96 prefix: [root@v6client:etc]# dig @2001:db8:123:64::1 google.com ; <<>> DiG 9.4.2-P2 <<>> @2001:db8:123:64::1 google.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30572 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com.IN ;; ANSWER SECTION: google.com. 300 IN 64:ff9b::d155:9468 google.com. 300 IN 64:ff9b::d155:9467 google.com. 300 IN 64:ff9b::d155:9469 google.com. 300 IN 64:ff9b::d155:9493 google.com. 300 IN 64:ff9b::d155:946a google.com. 300 IN 64:ff9b::d155:9463 ;; AUTHORITY SECTION: google.com. 8019IN NS ns3.google.com. google.com. 8019IN NS ns1.google.com. google.com. 8019IN NS ns4.google.com. google.com. 8019IN NS ns2.google.com. ;; Query time: 71 msec ;; SERVER: 2001:db8:123:64::1#53(2001:db8:123:64::1) ;; WHEN: Sun Nov 6 13:25:08 2011 ;; MSG SIZE rcvd: 308 C) ping6 from IPv6-only client to google.com on the IPv4 Internet via the NAT64 gateway works: [root@v6client:etc]# ping6 64:ff9b::d155:9469 PING6(56=40+8+8 bytes) 2001:db8:123:64:20c:29ff:feaf:ad2f --> 64:ff9b::d155:9469 16 bytes from 64:ff9b::d155:9469, icmp_seq=0 hlim=55 time=23.094 ms 16 bytes from 64:ff9b::d155:9469, icmp_seq=1 hlim=55 time=22.825 ms 16 bytes from 64:ff9b::d155:9469, icmp_seq=2 hlim=55 time=22.762 ms ^C --- 64:ff9b::d155:9469 ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 22.762/22.894/23.094/0.144 ms [root@v64gate:~]# tcpdump -i vic1 -nv icmp6 tcpdump: listening on vic1, link-type EN10MB 14:49:05.583129 2001:db8:123:64:20c:29ff:feaf:ad2f > 64:ff9b::d155:9469: icmp6: echo request (id:7397 seq:0) (len 16, hlim 64) 14:49:05.605904 64:ff9b::d155:9469 > 2001:db8:123:64:20c:29ff:feaf:ad2f: icmp6: echo reply (id:7397 seq:0) (len 16, hlim 55) 14:49:06.589012 2001:db8:123:64:20c:29ff:feaf:ad2f > 64:ff9b::d155:9469: icmp6: echo request (id:7397 seq:1) (len 16, hlim
Re: MPLS: Disable Penultimate Hop Popping?
> What kind of HW do you use? The MPLS test setup is made from five ALIX boards, three as P routers in the core connected in a triangle, and two as PE routers. > I do my tests with little soekris boxes and > there the RTT is in the range of 4-5ms and indistinguishable from non MPLS > operation. After updating to -current as of this morning, I still observe RTTs of 113 ms when pinging from one PE router to the over PE via two P routers. I have been checking the usual suspects, such as duplex-mismatch, but from tcpdumps it looks as if the P routers take two to three douzen milliseconds before they route returning ICMP Echo Replies. Later, I'll try to compile and post a more precise analysis, possibly with timestamped traces, etc.
Re: MPLS: Disable Penultimate Hop Popping?
Here is a fix for the PHP issue. Great, it fixes the problem. Thank you very much. The test setup works now, although I had no time yet for in-depth testing with other traffic than just ICMP pings. But pings from pe11 to pe21 make it now back to pe11 while p1 and p2 both do PHP. However, in a brief test I observed that the RTT from pe11 to pe21 via p1 and p2 and back is 73 ms. Sniffing on the interface of the target pe21, I see that it takes 13 ms from the time the routed, label-stripped Echo Request comes in, until the labeled Echo Reply is sent back to p2. I hope to find some time tomorrow to take a close look at p2, p1 and pe11 in order to try and figure out why the RTT sums up to 73 ms where I expect it to be in the order of a few ms only. Rolf
Re: MPLS: Disable Penultimate Hop Popping?
> Yeah, the packets are dropped in the POP case of mpls_input.c that's how > far I got until now. I started with a fix but my magic is not strong > enough for now. After taking a look at the source, I essentially backed out changes done in rev. 1.10 /src/usr.sbin/ldpd/kroute.c . Now my test setup works *somehow* even though the LFIB still shows that LDP applies PHP: [r...@p2:root]# ldpctl sh lfib 3.2.1.1 flags: * = valid, C = Connected, S = Static Flags Destination Nexthop Local Label Remote Label *R 3.2.1.0/30 2.2.1.2 20Pop But the kernel routing table is different, e.g. it applies no PHP but does SWAP the labels, as desired : [r...@p2:root]# route -n show -mpls Routing tables MPLS: In label Out label Op GatewayFlags Refs Use Mtu Prio Interface 3 - LOCAL 127.0.0.1 UGT00 3320056 lo0 16- LOCAL 10.7.0.254 UGT00 -56 udav0 173 SWAP 1.1.2.1UGT00 -56 vr2 183 SWAP 1.1.2.1UGT0 30 -56 vr2 1919SWAP 1.1.2.1UGT00 -56 vr2 203 SWAP 2.2.1.2UGT0 30 -56 vr0 <== 213 SWAP 2.2.1.2UGT00 -56 vr0 223 SWAP 2.2.1.2UGT00 -56 vr0 2323SWAP 1.1.2.1UGT00 -56 vr2 24- LOCAL 7.0.0.2UGT00 3320056 lo1 2517SWAP 1.2.3.3UGT00 -56 vr1 2626SWAP 1.1.2.1UGT00 -56 vr2 2726SWAP 2.2.1.2UGT00 -56 vr0 Also, the RTT for the pings is approx. 150 ms (and increasing) which should be in the 1 ms range: [r...@pe11:root]# ping 3.2.1.1 PING 3.2.1.1 (3.2.1.1): 56 data bytes 64 bytes from 3.2.1.1: icmp_seq=364 ttl=252 time=113.307 ms 64 bytes from 3.2.1.1: icmp_seq=365 ttl=252 time=113.211 ms 64 bytes from 3.2.1.1: icmp_seq=366 ttl=252 time=113.285 ms 64 bytes from 3.2.1.1: icmp_seq=367 ttl=252 time=113.260 ms 64 bytes from 3.2.1.1: icmp_seq=368 ttl=252 time=113.204 ms 64 bytes from 3.2.1.1: icmp_seq=369 ttl=252 time=152.024 ms 64 bytes from 3.2.1.1: icmp_seq=370 ttl=252 time=151.746 ms 64 bytes from 3.2.1.1: icmp_seq=371 ttl=252 time=151.777 ms 64 bytes from 3.2.1.1: icmp_seq=373 ttl=252 time=151.778 ms 64 bytes from 3.2.1.1: icmp_seq=374 ttl=252 time=151.753 ms 64 bytes from 3.2.1.1: icmp_seq=375 ttl=252 time=151.729 ms 64 bytes from 3.2.1.1: icmp_seq=376 ttl=252 time=151.782 ms 64 bytes from 3.2.1.1: icmp_seq=377 ttl=252 time=151.789 ms 64 bytes from 3.2.1.1: icmp_seq=378 ttl=252 time=151.760 ms 64 bytes from 3.2.1.1: icmp_seq=379 ttl=252 time=151.712 ms 64 bytes from 3.2.1.1: icmp_seq=380 ttl=252 time=151.787 ms 64 bytes from 3.2.1.1: icmp_seq=381 ttl=252 time=151.853 ms 64 bytes from 3.2.1.1: icmp_seq=382 ttl=252 time=151.798 ms 64 bytes from 3.2.1.1: icmp_seq=383 ttl=252 time=190.438 ms 64 bytes from 3.2.1.1: icmp_seq=384 ttl=252 time=190.347 ms 64 bytes from 3.2.1.1: icmp_seq=385 ttl=252 time=190.349 ms 64 bytes from 3.2.1.1: icmp_seq=386 ttl=252 time=190.395 ms 64 bytes from 3.2.1.1: icmp_seq=387 ttl=252 time=190.315 ms 64 bytes from 3.2.1.1: icmp_seq=388 ttl=252 time=190.316 ms 64 bytes from 3.2.1.1: icmp_seq=389 ttl=252 time=190.309 ms Obviously, I did not understand enough about the code yet...
Re: MPLS: Disable Penultimate Hop Popping?
Thanks Claudio for your speedy reply. > Have a look at the route -n show -mpls output and check the input counter for label 20. It happily counts and confirms what tcpdump shows on the ingress interface: [r...@p2:root]# route -n show -mpls Routing tables MPLS: In label Out label Op GatewayFlags Refs Use Mtu Prio Interface 3 - LOCAL 127.0.0.1 UGT00 3320056 lo0 16- LOCAL 10.7.0.254 UGT00 -56 udav0 17- POP1.1.2.1UGT00 -56 vr2 18- POP1.1.2.1UGT05 -56 vr2 1919SWAP 1.1.2.1UGT00 -56 vr2 20- POP2.2.1.2UGT0 7526 -56 vr0 <== 21- POP2.2.1.2UGT00 -56 vr0 22- POP2.2.1.2UGT00 -56 vr0 2323SWAP 1.1.2.1UGT00 -56 vr2 24- LOCAL 7.0.0.2UGT01 3320056 lo1 2517SWAP 1.2.3.3UGT00 -56 vr1 2626SWAP 1.1.2.1UGT00 -56 vr2 2726SWAP 2.2.1.2UGT00 -56 vr0 Also, I have re-checked the counters of all other routes as well as the traffic out of all other interface on this P router, but the packets do not appear on a "wrong" interface. > Setup looks fine. I use OSPF as IGP but I now Michele is using RIP in his setup. For a cross-check, I will move from RIP to OSPF and report again if it made any difference. > Please consider using IP blocks that are available for testing and not publicly assigned ones. But it so much more convenient with short addresses which reflect the topology, although there is actually named running as well. As a precaution against leakage into the wild Internet, I had added those public ranges temporarily to the RFC1918 egress filter on my pf lab firewall :-)
MPLS: Disable Penultimate Hop Popping?
Dear list, Is there an way to disable PHP, e.g. to prevent ldpd on the last P router from stripping/popping the label before it reaches the PE router? In my little test network that runs -current as of 03 June, I observe from ldpd's lfib on the last P router that it pops the label on the ingress interface (see output below), but then it never outputs/routes the stripped packet to the egress interface towards the PE router (the use counter of the matching prefix on the P router does not increment, e.g. the P router appears to blackhole the ICMP Echo Request packets). Currently, I am using a very basic setup with RIP as IGP, LDP, without any additional route tables, nor VLANs, pf is disabled on all nodes. I can provide a more detailed description of my lab setup, and output of the various routing tables, etc. However, if there would be an easy way to disable PHP, then that would confirm that my setup is indeed OK (as I have tried to verify manually so far). Thank you, Rolf We ping from another PE router pe11 via two P routers p1 and p2 to another PE router pe21=3.2.1.1: [r...@pe11:root]# ping 3.2.1.1 The label switched packet makes it via another P router p1 to the ingress interface of the last P router p2 just fine: [r...@p2:root]# tcpdump -i vr2 -n tcpdump: listening on vr2, link-type EN10MB 18:34:39.071600 MPLS(label 0x14, exp 0, ttl 254) 2.1.1.2 > 3.2.1.1: icmp: echo request 18:34:40.091795 MPLS(label 0x14, exp 0, ttl 254) 2.1.1.2 > 3.2.1.1: icmp: echo request 18:34:41.111994 MPLS(label 0x14, exp 0, ttl 254) 2.1.1.2 > 3.2.1.1: icmp: echo request According to the LFIB this P router knows it is the Penultimate Hop which directly connects to pe21. Therefore (probably), it pops the label 20: [r...@p2:root]# ldpctl show lfib flags: * = valid, C = Connected, S = Static Flags Destination Nexthop Local Label Remote Label *S 0.0.0.0/010.7.0.25416- *C 1.1.2.0/29 link#3imp-null - *R 1.1.3.0/29 1.1.2.1 17Pop *C 1.2.3.0/29 link#2imp-null - *R 2.1.1.0/30 1.1.2.1 18Pop *C 2.2.1.0/30 link#1imp-null - *R 3.1.1.0/30 1.1.2.1 1919 *R 3.2.1.0/30 2.2.1.2 20Pop <== *R 3.2.1.4/30 2.2.1.2 21Pop *R 3.2.1.8/30 2.2.1.2 22Pop *R 7.0.0.1/32 1.1.2.1 2323 * 7.0.0.2/32 7.0.0.2 24- *R 7.0.0.3/32 1.2.3.3 2517 *R 7.0.0.11/32 1.1.2.1 2626 *R 7.0.0.21/32 2.2.1.2 2726 *C 10.7.0.0/16 link#6imp-null - *C 127.0.0.0/8 link#0- - *S 127.0.0.0/8 127.0.0.1 - - * 127.0.0.1/32 127.0.0.1 - - *S 224.0.0.0/4 127.0.0.1 - - * 224.0.0.9/32 127.0.0.1 - - [r...@p2:root]# ripctl show rib Destination Nexthop Cost 1.1.2.0/29 0.0.0.0 1 1.1.3.0/29 1.1.2.1 2 1.2.3.0/29 0.0.0.0 1 2.1.1.0/30 1.1.2.1 2 2.2.1.0/30 0.0.0.0 1 3.1.1.0/30 1.1.2.1 3 3.2.1.0/30 2.2.1.2 2 <== 3.2.1.4/30 2.2.1.2 2 3.2.1.8/30 2.2.1.2 2 7.0.0.1/32 1.1.2.1 2 7.0.0.2/32 7.0.0.2 1 7.0.0.3/32 1.2.3.3 2 7.0.0.11/32 1.1.2.1 3 7.0.0.21/32 2.2.1.2 2 [r...@p2:root]# route -n get 3.2.1.1 route to: 3.2.1.1 destination: 3.2.1.0 mask: 255.255.255.252 gateway: 2.2.1.2 interface: vr0 if address: 2.2.1.1 priority: 40 (rip) flags: use mtuexpire 49 0 0 But p2 appears to eat up those packets, instead of forwarding them to the egress interface vr0: [r...@p2:root]# tcpdump -i vr0 -nvv tcpdump: listening on vr0, link-type EN10MB 18:45:53.449355 2.2.1.2.646 > 224.0.0.2.646: [udp sum ok] udp 26 [tos 0xc0] [ttl 1] (id 64128, len 54) 18:45:53.682729 2.2.1.1.646 > 224.0.0.2.646: [udp sum ok] udp 26 [tos 0xc0] [ttl 1] (id 6099, len 54) 18:45:58.460172 2.2.1.2.646 > 224.0.0.2.646: [udp sum ok] udp 26 [tos 0xc0] [ttl 1] (id 6759, len 54) ^C 4 packets received by filter 0 packets dropped by kernel Note that IP forwarding is enabled on all P and PE routers, e.g. sysctl net.inet.ip.forwarding=1 .
Re: gcc4,amd64 - mk.conf?
> if this solves the compile error I had encoutered while building the userland, Yes, it did. After setting COMPILER_VERSION=gcc4 in /etc/mk.conf, re-compiling gcc4 with itself just to be on the safe side, then the builds of the kernel, userland, and finally xenocara were successful. This just took longer than one hour, but almost three hours on my Acer Timeline Aspire 3810T laptop, including the MPLS and mpe kernel options... Rolf
OpenBSD on Freescale QorIQ ?
Is anyone working on moving macppc or socppc to the Freescale QorIQ (e500 PowerQICC core)? Although I have no hardware / evaluation board yet myself, I am looking into supporting this low-power architecture as a hobby project, in order to brush up my low level programming skills a bit. Rolf
Re: gcc4,amd64 - mk.conf?
> Does it make any difference having it in mk.conf or not? At the moment, I am looking into the same question. Yesterday, I went through the compiler upgrade steps on an i386-current machine. Probably, I have ended up with a gcc3-compiled gcc4 on my i386 system, although I had thought I had re-compiled gcc4 with itself as per the second step of the instructions in the the FAQ. However, after looking at /usr/src/share/mk/bsd.own.mk (see snipplet below) it looks to me as if gcc4 is currently only set "automagically" on am64 and sparc64. Right now, I am trying to re-compile (on my i386 machine) gcc4 with itself after having set COMPILER_VERSION=gcc4 manually in /etc/mk.conf , as per Marco's instructions. In an hour or so I should know if this solves the compile error I had encoutered while building the userland, although the building of the kernel was fine (still on i386). As per Marco's table, gcc4 is OK also on i386. Rolf ... # gcc3 .if ${MACHINE_ARCH} == "m68k" || ${MACHINE_ARCH} == "m88k" || \ ${MACHINE_ARCH} == "sparc" || ${MACHINE_ARCH} == "vax" USE_GCC3?=no COMPILER_VERSION?=gcc2 .elif ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "sparc64" COMPILER_VERSION?=gcc4 .else USE_GCC3?=yes COMPILER_VERSION?=gcc3 .endif ...
Re: Virtual pseudo-device 'vwire()' anyone?
On Fri, Dec 25, 2009 at 2:37 PM, Csaba Szip wrote: > OpenBSD has some network virtualization (not yet fully ready?) stuff > in the tree called rdomain. I reading the current documentation, but i > dont find any solution to interconnect two rdomain. I create two > vether interface in different rdomain and switched them, but it doesnt > work. So that would be nice if this vwire (or similar) device will be > provided and coexist with rdomain. Hello Csszep, what you need to "glue" rdomains together is _routing_ (combined eventually with some firewalling by pf) which operates at network layer-3 level, based on IP addresses etc. in IP packet headers. The purpose of vwire however is to establish a connection between two bridges which may have ether(4), other pseudo-device such as tunX, and real physical interfaces as members. Thus vwire "glues" together two bridges which become like a large virtual switch with the member interfaces being switch ports. Note that the bridge and the interconnecting vwire operate at link layer-2 exclusively, e.g. we consider _switching_ which looks only at MAC addresses of Ethernet frames. Thus, vwire will not even (need to) be aware of the protocols used by the payload which these switched Ethernet frames encapsulate. vwire will essentially just be bi-directional pipes which transport bits between two bridges. In order to make things interesting, these pipes might introduce some distortion into those bit streams, like loosing occasionally some bits, delay them, etc. vwire will be a link layer-2 device, much like a UTP cables with some "bumps" in it. It will not know anything about IP nor routing network layer-3. Regards, Rolf
Re: Virtual pseudo-device 'vwire()' anyone?
> Have you ever looked at > http://vde.sourceforge.net/ > ? Thanks Chris for your hint, which triggered me to take a look at the VDE project on Sourceforge. Before posting, I was actually reading the documentation WIki of Virtual Square (V^2) at http://wiki.virtualsquare.org . Currently, V^2 and VDE look to me like a very much more comprehensive and complex project. Still, I am unsure about how much of the VDE code is actually specific to (qemu under) Linux. What I am after with vwire is only a tiny subset of that. At the moment, I study the source of vether(4) and try to derive a simple cross-over vwire pseudo-device from it to start with. Which, of course, would be redundant and simply could be eliminated by bridging all interfaces in a single bridge, unless the capability of this simple wire is augmented by channel simulation/emulation features. Then the vwire can link several bridges which run on the same OpenBSD host and 'distort' transmissions between those bridges at Link level (layer-2), for example introduce bit errors, cause bit & frame loss, insert delay, etc. Regards, Rolf
Virtual pseudo-device 'vwire()' anyone?
Recently, developers added the pseudo-device vether(4). Such virtual switch ports can be member of bridges. An additional pseudo-device 'vwire' would come in handy to interconnect two or more switches in a virtualized environment, without necessarily bridging to a physical switch port as well. In addition to providing a simple virtual wire, such a 'vwire' pseudo-device offers certain properties, such as delay, loss, jitter, MTU size, etc. Over time, 'vwire' could evolve to a digital "channel simulator" or even a "link emulator", similar to 'dummynet' for example which was/is used by m0n0wall and pfSense (primarily to implement traffic shaping/policing though). The description http://open-mesh.net/wiki/Emulation comes very close to what I am trying to setup on my OpenBSD laptop as a physical OpenBSD host, in order to emulate a network with several virtual OpenBSD machines as guests using qemu (e.g. a bunch of P, PE and CE routers of a MPLS network that uses lossy wireless links). Are you aware of anyone who may already work on an equivalent of 'wire_filter' and/or 'dummynet' in OpenBSD which connect bridges over virtual wires? Or do you have recommendations which existing pseudo-device(s) I should study first to get me started in the right direction with 'vwire'? Thank you, Rolf
Web GUI for named(8) ?
Hello list, Can you recommend any GUI that enables junior IT staff to maintain basic DNS Resource Records (such as for ex.. A, PTR, CNAME,...) for BIND 9 running on OpenBSD? Also, I will consider alternatives to named(8), provided that they support an authoritative, split DNS server and some simple GUI, all running on OpenBSD. So far, I have been looking at webmin, Binder, smbind, ProBIND, DNS Control, adadns. None of them appears to have a OpenBSD port yet. Their maturity & development activity appears to vary widely. Thanks for any hints, Rolf
OTi Thunderbird USB Bridge in cdce(4)
In an attempt to stack ALIX boards using their USB interfaces (actually to emulate an MPLS core in the lab with three ALIX boards connected in a triangle as P routers over 480 Mbit/s USB "core" links), I picked up a USB to USB bridge at the local supermarket. This 20$ USB bridge is branded "connection, ednet elecom Group, USB Easy Datalink, USB 2.0 Link Cable A/A, Art.-No. 84256". I was gambling that it has a chipset built-in which is supported by cdce(4), such as the Prolific PL250x. It looks as if I am without luck and its OTi chipset (OTi002108-G ?) is not (yet) supported. On i386-current, it appears as a SCSI drive which holds an executable file for Windows, much like 2G/3G adapters like umsm(4) do: # dmesg ... umass1 at uhub1 port 1 configuration 1 interface 0 "USB Transfer line" rev 2.00/1.00 addr 3 umass1: using SCSI over Bulk-Only scsibus2 at umass1: 2 targets, initiator 0 sd1 at scsibus2 targ 1 lun 0: SCSI2 0/direct removable sd1: 0MB, 512 bytes/sec, 992 sec total ... # mount /dev/sd1i /mnt # ls -al /mnt -rwxr-xr-x 1 root wheel 409600 Nov 16 2005 EasySuite.exe # usbdevs -v ... port 1 addr 3: high speed, power 250 mA, config 1, Transfer line(0x2108), USB(0x0ea0), rev 1.00 ... After manually adding the new device to usbdevs, it attaches to cdce0 in the freshly built kernel: # dmesg ... cdce0 at uhub0 port 1 configuration 1 interface 0 "USB Transfer line" rev 2.00/1.00 addr 2 cdce0: address 2a:cb:05:b8:12:00 ... # ifconfig cdce0 10.8.0.11 netmask 255.255.255.0 up # ifconfig cdce0 cdce0: flags=8843 mtu 1500 lladdr 2a:cb:05:b8:b3:00 priority: 0 inet6 fe80::28cb:5ff:feb8:b300%cdce0 prefixlen 64 scopeid 0x6 inet 10.8.0.11 netmask 0xff00 broadcast 10.8.0.255 But pinging the peer on the other end of the USB bridge fails, which has got the link local address 2a:cb:05:b8:12:00 : # dmesg ... cdce0: usb error on rx: STALLED ... Did eventually anyone tried to integrate this USB bridge into cdce(4) before? Is there anything else I should try before giving up on this particular USB bridge cable, and to stack ALIX boards using their USB ports (in order to save the 3 Ethernet NICs to connect more ALIX boards as PE routers to the MPLS core :-)? Thanks for any hints, Rolf
Re: OT: 10GbE Physical Network Taps
> (There is/was a voice/video recording if the session, but I can find > it right now.) Here is the link to the presentation Arien held a year later, and this one has pointers to videos of his talk: 10GE monitoring live! How to find that special one out of millions http://events.ccc.de/congress/2007/Fahrplan/events/2285.en.html
Re: OT: 10GbE Physical Network Taps
> I need to collect raw throughput statistics without increasing latency > or reducing bandwidth on 10GbE fiber links, so most of the typical > methods are out of the question After re-reading your post(s) and the thread, I am still unsure what level of detail you need, e.g. what you mean by "collect raw throughput statistics". Does that go more in-depth than simple Byte- or packet counts which you might read by SNMP GETs from a network device in your path? Or would a NetFlow or sFlow export provide enough level of detail for those statistics? Arien Vijn from AMS-IX has given some interesting presentations on monitoring 10GE, also using the Meta / Force10 Networks "programmable NIC" and a photonic cross connect/splitter: http://events.ccc.de/congress/2006/Fahrplan/events/1640.en.html (There is/was a voice/video recording if the session, but I can find it right now.) Another source for similar special NICs: http://www.napatech.com Rolf
Re: Testing in a virtual environment
OpenBSD i386-current works fine in VirtualIron http://www.virtualiron.com/, which is an attractive Xen-based alternative to VMware ESX. I have not tried to run amd64 as a guest in VirtualIron yet. Nor have I checked if VItools have been ported to OpenBSD since I last looked into its source one year ago.
Re: ldattach dies after gpsd starts
> Do you see this as well when you use ldattach on cua00? Yes the same, no change/improvement. from /var/log/messages: ldattach[23199]: eof during read from device: Undefined error: 0 ldattach[20370]: eof during read from device: Input/output error
ldattach dies after gpsd starts
Hello, since a few i386 snapshot, and also in the latest GENERIC#1012 i386, I observe that # /sbin/ldattach -p -s 4800 -t dcd nmea tty00 dies once I start # /usr/local/sbin/gpsd -N -D 2 /dev/ttyp1 This was working fine still with GENERIC#936 from mid January, shortly after mbalmer@ added the '-p' option to ldattach. I sthere anything I can do to help debugging this? Thanks. Regards, Rolf
Re: Setting priority on interface fails in latest snapshot
cjeker wrote: > This diff got removed from the latest snaps. Thanks for prompt reply. That's bad news, as I am using it on the firewall cluster to resolve a problem in connection with default routes and dhclient, as per your previous recommendation. Is this removal just a temporary measure until some isse is solved, or will interface priorities not return at all, e.g. do I need to go back to ifstated for some crutches? Rolf
Setting priority on interface fails in latest snapshot
After updating my i386 firewall cluster to the latest snapshot (16 Jul, 22:15) # ifconfig vr0 priority 2 ifconfig: priority: bad value Is this a regression, or did the syntax change since my last update about one week ago? I did re-read the man page and also looked through the CVS commits, but did not find any obvious hints. Thanks, Rolf
memory leak with filtering bridges in i386 snapshot
The weekend before the hackaton started, I updated my 2-stage firewall clusters at home, where the outer stage is setup as a filtering bridge cluster, and the inner stage is setup as a filtering router cluster. Both clusters are currently operating in active-passive mode, using pfsync, carp, ifstated, etc. After the update to the current snapshop of Saturday June 7, I observed loosing memory at a rate of about 12 MByte per day, on both the inner and outer cluster nodes. (I use Cacti to SNMP get memory usage and graph free memory.) Two days ago, I updated all four node to the latest snapshot again. Since, the leak has apparently been plugged on the filtering router inner firewall nodes. But it persists on the two filtering bridges outer firewall node. The leak rate is the same for the active and the passive node, still about 12 MByte per day. I remember we had such a situation in fall last year. If I recall correctly, pfsync was the culprit then which required some plumbing which was done by reyk@ or [EMAIL PROTECTED] Rolf
dhcpd sync
After updating my home firewall cluster (two ALIX boards) to the i386 snapshot two days ago, I proceeded to try the great new sync feature of dhcpd. Before, each of the cluster node was running its independent instance of dhcpd, each dishing out from non-overlapping IP address ranges, independent of a cluster node being in Master or in Backup state (currently the cluster is active-passive). Both nodes have in /etc/rc.conf.local : dhcpd_flags="-Y vlan20 -y vlan20 vr0" # sync using multicast to 224.0.1.240 and in /etc/pf.conf : # pfsync pass log quick on vlan20 proto pfsync keep state (no-sync) # spmd and dhcpd use multicasts to 224.0.1.240 for their sync pass log quick on vlan20 proto igmp keep state (no-sync) While testing dhcpd sync and devising a pf rule for it, looking at 'tcpdump -i vlan20' triggered the following remarks and questions: a) It might be helpful to document in the SYNCHRONISATION section of dhcpd(8) that 'proto icmp' is being used. This facilitates the life of those who must devise an additional pf rule. Symmetrically, the same would apply to spamd(8). pfsync(4) states for example: "The protocol is IP protocol 240, PF- SYNC, and the multicast group used is 224.0.0.240." b) When dhcpd starts and no /var/db/dhcpd.leases exists, then dhcpd create an empty lease file. Well, not exactly empty, but there are just two comment lines in it, which is fine. However, when a /var/db/dhcpd.leases still holds leases from a previous session, the starting dhcpd does not clear thoses leases (e.g. leases are persistent also in my case where an rsny restores the state prior to reboot to ramdisk from CompactFlash). Nor does it apparently get a bulk update from the dhcpd instances running on other nodes (which are supposedly in sync, regardless if in active Master or in passive Backup state). pfsync has such a mechanism. Is something similar already in dhcpd's sync (and spamd's sync), and did I simply miss it? Or is it on the to do list? I guess it would be at least a nice to have to assert coherent dhcpd (and spamd) state among the nodes, although dhclient (unlike pf) can cope also while offered "incoherent" leases... c) My setup uses the same VLAN for both the multicasts of dhcpd and spamd (and pfsync as well). Besides potentially different shared keys in /var/db/dhcpd.key and in /etc/mail/spamd.key, if authentication is used at all, there is no obvious discriminator to tell the difference between a dhcpd sync and a spamd sync frame. Rapid inspection of /usr/src/usr.sbin/dhcpd.(h|c) and /usr/src/libexec/spamd.(h|c) reveals that apparently the only differences are #define DHCPD_SYNC_VERSION 1 in dhcpd.h #define SPAM_SYNC_VERSION 2 in spamd.h For situations like mine where both dhcpd and spamd sync over the same interface, would it be safer/necessary to either add an additional application protocol flag, or to use different multicast addresses? I would like to thank the developers for this nice new feature which simplifies the configuration of the dhcp.conf file on my nodes and makes them symmetric like most other configuration files in the cluster. Rolf
Re: asus eee ethernet and 4.3
Just found that my previous analysis was flawed. The problem is not related to the length of the patch cable. lii(4) comes up correctly if the eeePC is connected to the switch at the time when the eeePC is powered on. However, if the eeePC is not plugged in to the switch at powerup, then there seems to be no way to bring the link up later. Even a reboot does not help. Only cycling power appears to bring up the link to active state, and independent of the length of the patch cable. Will take another look at the startup code in lii(4).
Re: asus eee ethernet and 4.3
I have observed the same problem with lii(4) not linking up running the latest i386 snapshot, and using a 10 meter patch cable to the switch. However, when trying a short 1 m cable to the same switch port the link comes up! A fresh kernel build this past weekend from CVS exhibits the same behaviour. Interestingly, under Linux/Xandros even the 10 m cable works fine. Eventually, some MII parameters in lii(4) need to be tweaked to make link detection work also for longer cables? I am not afraid to try and compile a patched driver on a fresh CVS tree, if there are any suggestions which parameters to tweak. Rolf
Re: relayd layer 7 http proxy and filtering questions
> As a test, the URL or path filtering can allow "/", "*.html" and "*.jpg". > We are unable to figure out how to get relayd to allow only these types of files, and deny any other access. Same question here as I was unable to find answers yet either, after studing the man pages, trial-and-error testing and finally looking at the source of relayd. But before giving up and returning to Pound, I was about to contact the authors (reyk@, pyr@) for guidance. Thus I'd be interested in any hints and working examples, too. Then, for one outcome, we might try to improve relayd's man page section about filtering. Thanks, Rolf
glxpcib: tiny bug fix
Without the fix below, reading back the state of the impulse switch (GPIO24) on my ALIX always returned '0' (e.g. switch is pressed). Now it returns '1' if depressed, and '0' only while pressing it, as expected. As AMD5536_GPIO_READ_BACK was already #defined but so far unused, I assume it was just a small oversight which crept through testing while reading back the LEDs' state only. See p. 480ff in the CS4436 Companion Data Book for a detailed description of the registers in question. Note: This fix changes the values returned while reading the LEDs' state (GPIO6, 25 and 27). Before, they alway reflected the last state written (LED on or off). Now, they always return '0', unless you set 'in' flag, upon which it returns always '1'. The LEDs' current state can't be read back anymore this manner because these GPIOs do not support the 'inout' flag. Rolf --- sys/arch/i386/pci/glxpcib.c.origSat Nov 24 09:21:00 2007 +++ sys/arch/i386/pci/glxpcib.c Tue Mar 18 15:55:51 2008 @@ -291,7 +291,7 @@ u_int32_t data; int reg; - reg = AMD5536_GPIO_OUT_VAL; + reg = AMD5536_GPIO_READ_BACK; if (pin > 15) { pin &= 0x0f; reg += AMD5536_GPIOH_OFFSET;
Re: Regression: Latest i386 Snapshot fails to boot on WRAP, OK on ALIX
> I couldn't find a copy of #662 but I don't see this with #663 on my WRAP... I confirm that #663 also boots on my WRAP (and it also does on ALIX). The snapshot with #663 has not yet made it to the mirrors in Europe, thus I pulled just the kernel file "bsd" from the fan out server. Thanks for your heads up, Rolf
Regression: Latest i386 Snapshot fails to boot on WRAP, OK on ALIX
The kernel "4.3 GENERIC#662 i386" from the latest snapshot fails to boot on WRAP, whereas it boots fine on ALIX and on other i386 machines. Whereas the kernel from the previous snapshot "4.3 GENERIC#661 i386" boots fine on WRAP and others, such as ALIX. PC Engines WRAP.1C/1D/1E v1.11 640 KB Base Memory 130048 KB Extended Memory 01F0 Master 044A CF 4GB Phys C/H/S 7866/16/63 Log C/H/S 983/128/63 Using drive 0, partition 3; Loading;... probing: pc0 com0 pci mem[640K 127M a20=on] disk: hd0 >> OpenBSD/i386 BOOT 3.01 - com0: 38400 baud switching console to com0 >> OpenBSD/i386 BOOT 3.01 boot> booting hd0a:/bsd: 5924880+873540=0x67bdc8 entry point at 0x200120 Console output stops here with GENERIC#662 on WRAP and machine appears to hang until power cycled. Regards, Rolf
Re: reboot(8) fails on Sun Fire X4100 M2 with latest i386.mp snapshot
On Jan 19, 2008 5:04 AM, Jonathan Gray <[EMAIL PROTECTED]> wrote: > Try this diff: Great, that fixed it, thank you. Now, will you commit it so that it will be included in a next snapshot?
reboot(8) fails on Sun Fire X4100 M2 with latest i386.mp snapshot
Hello misc, after a successful upgrade of a X4100 M2 to the latest snapshot, the server fails to reboot after having issued the reboot(8) command as root. This was working fine before with the snapshot which was from early December (also i386 .mp, ACPI enabled manually back then, which is now implicit). Last output on the console is (which is normal): syncing disks...done rebooting... Then nothing happens until I reset the server manually (from remote via iLOM). I have not touched /etc/rc.shutdown, e.g. powerdown=NO. Otherwise, I have not observed any regressions yet, although this firewall/gateway machine runs a comprehensive collection of interfaces (trunks, vlans, carps), pf rules, and some proxies as peer in a cluster. But I'll wait with the upgrade from remote of the other, primary cluster node until the reboot works :-) Thanks for any hints what I should try first. Regards, Rolf OpenBSD 4.2-current (GENERIC.MP) #546: Tue Jan 15 12:11:19 MST 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Dual-Core AMD Opteron(tm) Processor 2210 ("AuthenticAMD" 686-class, 1024KB L2 cache) 1.80 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16 real mem = 2146979840 (2047MB) avail mem = 2068090880 (1972MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 04/11/07, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.3 @ 0xfbd50 (70 entries) bios0: vendor American Megatrends Inc. version "0ABJX039" date 04/11/2007 bios0: Sun Microsystems Sun Fire X4100 M2 acpi0 at bios0: rev 2 acpi0: tables DSDT FACP APIC SPCR SLIT OEMB HPET IPET SRAT SSDT acpi0: wakeup devices PS2K(S0) PS2M(S0) USB0(S0) USB1(S0) MAC_(S5) P0P1(S0) P0P2(S0) P0P3(S0) P0P4(S0) P0P5(S0) IO4B(S0) BR5B(S0) BR5C(S0) BR5D(S0) BR5E(S0) IOB2(S0) BR2B(S0) BR2C(S0) BR2D(S0) BR2E(S0) PWRB(S0) 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 199 MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Dual-Core AMD Opteron(tm) Processor 2210 ("AuthenticAMD" 686-class, 1024KB L2 cache) 1.80 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16 ioapic0 at mainbus0: apid 15 pa 0xfec0, version 11, 24 pins ioapic1 at mainbus0: apid 16 pa 0xfeafd000, version 11, 7 pins ioapic1: misconfigured as apic 0, can't remap to apid 16 ioapic2 at mainbus0: apid 17 pa 0xfeafc000, version 11, 7 pins ioapic2: misconfigured as apic 1, can't remap to apid 17 ioapic3 at mainbus0: apid 14 pa 0xfeaff000, version 11, 24 pins acpihpet0 at acpi0: 2500 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus 4 (P0P4) acpiprt3 at acpi0: bus 5 (P0P5) acpiprt4 at acpi0: bus 128 (PCIC) acpiprt5 at acpi0: bus 133 (POGA) acpiprt6 at acpi0: bus 134 (POGB) acpicpu0 at acpi0: PSS acpicpu1 at acpi0: PSS acpibtn0 at acpi0: PWRB bios0: ROM list: 0xc/0xa000 0xca000/0x1800 0xcb800/0x1000 0xcc800/0x1000 0xcd800/0x5c00 0xd3800/0x1000 ipmi at mainbus0 not configured cpu0: PowerNow! K8 1796 MHz: speeds: 1800 1000 MHz pci0 at mainbus0 bus 0: configuration mode 1 (no bios) "NVIDIA nForce4 DDR" rev 0xa3 at pci0 dev 0 function 0 not configured pcib0 at pci0 dev 1 function 0 "NVIDIA nForce4 ISA" rev 0xa3 nviic0 at pci0 dev 1 function 1 "NVIDIA nForce4 SMBus" rev 0xa2 iic0 at nviic0 iic1 at nviic0 iic1: addr 0x18 00=01 01=01 02=00 03=00 words 00=0101 01=0101 02= 03= 04= 05= 06= 07= 08= 09= 0a= 0b= 0c= 0d= 0e= 0f= iic1: addr 0x19 00=01 01=00 02=00 03=01 words 00=0101 01= 02= 03=0101 04= 05= 06= 07= 08= 09= 0a= 0b= 0c= 0d= 0e= 0f= iic1: addr 0x1a 02=00 03=00 words 00= 01= 02= 03= 04= 05= 06= 07= 08= 09= 0a= 0b= 0c= 0d= 0e= 0f= iic1: addr 0x1c 02=00 03=00 words 00= 01= 02= 03= 04= 05= 06= 07= 08= 09= 0a= 0b= 0c= 0d= 0e= 0f= iic1: addr 0x1d 00=0f 01=0f 02=00 03=00 words 00=0f0f 01=0f0f 02= 03= 04= 05= 06= 07= 08= 09= 0a= 0b= 0c= 0d= 0e= 0f= iic1: addr 0x1e 01=07 02=00 03=f8 words 00= 01=0707 02= 03=f8f8 04= 05= 06= 07= 08= 09= 0a= 0b= 0c= 0d= 0e= 0f= admcts0 at iic1 addr 0x2c admcts1 at iic1 addr 0x2d iic1: addr 0x48 00=ff 01=00 02=ff 03=ff 04=00 05=00 06=ff 07=ff 08=1b 09=00 0a=4b 10=1b 11=00 12=4b 18=1b 19=00 1a=4b 20=1b 21=00 22=4b 28=1b 29=00 2a=4b 30=1b 31=00 32=4b 38=1b 39=00 3a=4b 3e=1b 40=1b 41=00 42=4b 48=1b 49=00 4a=4b 4e=1b 50=1b 51=00 52=4b 58=1b 59=00 5a=4b 60=1b 61=00 62=4b 68=1b 69=00 6a=4b 70=1b 71=00 72=4b 78=1b 79=00 7a=4b 80=1b 81=00 82=4b 88=1b 89=00 8a=4b 90=1b
Re: GENERIC -current kernel requires modification to boot on ALIX
On Jan 12, 2008 9:01 PM, Jan Stary <[EMAIL PROTECTED]> wrote: > I was testing the watchdog-enabled kernel on my ALIX.1C in October for > Marc Balmer ([EMAIL PROTECTED]) - he's the guy you want to contact. > ... > basically, the timer got correctly detected, but didn't really work > - both before and after upgrading the ALIX firmware. > > I will test again when I get me a new ALIX.2C3 some weeks from now. After running a few tests with the watchdog on two ALIX2C3, I can confirm that the hardware watchdog works fine using the GENERIC kernel from the latest -current snapshot with BIOS 0.99. To test, I have simpley disabled tickling by the kernel: sysctl kern.watchdog.auto=0 The watchdog bites within 30 seconds which is the default kern.watchdog.period=30 Running the userspace tickler watchdogd, which implicitly disables kern.watchdog.auto, successfully prevents the watchdog from biting, as it should be. Thanks to marc@ et al. who implemented & extended glxpcib for ALIX! Rolf
Re: Need some guidance booting OpenBSD on an ALIX device
On Jan 12, 2008 10:44 PM, Limaunion <[EMAIL PROTECTED]> wrote: > OpenBSD 4.2 (GENERIC) #375: Tue Aug 28 10:38:44 MDT 2007 Also note that you are using a kernel that is over four months old and it obviously does not yet contain the extensions that were added to glxpcib(4) to support the hardware timer for watchdogd, and the GPIO pins (see gpioctl(8) to control the LEDs, for example) , or security block acceleration glxsb(4). So maybe you want to upgrade the system on your CF card to the -current snapshot to be able to use these features. For reference, here is the dmesg of my ALIX that runs the latest snapshot: OpenBSD 4.2-current (GENERIC) #647: Fri Jan 11 02:06:06 MST 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 499 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX real mem = 268009472 (255MB) avail mem = 251240448 (239MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 12/10/07, BIOS32 rev. 0 @ 0xfceb2 acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xe/0xa800 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31 glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES vr0 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10, address 00:0d:b9:12:6c:10 ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 10 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address 00:0d:b9:12:6c:11 ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr2 at pci0 dev 11 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12, address 00:0d:b9:12:6c:12 ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 ral0 at pci0 dev 12 function 0 "Ralink RT2561" rev 0x00: irq 9, address 00:08:a1:9c:32:c4 ral0: MAC/BBP RT2661B, RF RT2527 glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 0, 32-bit 3579545Hz timer, watchdog, gpio gpio0 at glxpcib0: 32 pins pciide0 at pci0 dev 15 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 4-sector PIO, LBA, 977MB, 2001888 sectors wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 pciide0: channel 1 ignored (disabled) ohci0 at pci0 dev 15 function 4 "AMD CS5536 USB" rev 0x02: irq 15, version 1.0, legacy support ehci0 at pci0 dev 15 function 5 "AMD CS5536 USB" rev 0x02: irq 15 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1 isa0 at glxpcib0 isadma0 at isa0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pccom0: console usb1 at ohci0: USB revision 1.0 uhub1 at usb1 "AMD OHCI root hub" rev 1.00/1.00 addr 1 biomask e1ef netmask ffef ttymask ffef mtrr: K6-family MTRR support (2 registers) nvram: invalid checksum softraid0 at root root on wd0a swap on wd0b dump on wd0b
Re: Need some guidance booting OpenBSD on an ALIX device
On Jan 12, 2008 10:44 PM, Limaunion <[EMAIL PROTECTED]> wrote: > Well, I finally got it booting. As suggested I upgraded the BIOS to > release 0.99 and configured the device to work at 9k6bps. > Now the problem is that it gets stuck just before having the login > prompt, after printing the date and time, any idea ? Great - I guess that in your /etc/ttys the line or tty00 does not read yet like: tty00 "/usr/libexec/getty std.9600" vt220on secure
Re: Need some guidance booting OpenBSD on an ALIX device
> Any other suggestion ? It looks as if your ALIX booted through all stages and successfully loaded the kernel /bsd, but fails to start this kernel. Maybe check out http://www.openbsd.org/faq/faq14.html#Boot386 , notably item 4., to help with diagnosis and repair. Are you sure that the kernel /bsd on your CF card is ok? I would try and replace it temporarily by /bsd from the current snapshot. Also, I notice that your ALIX is still running BIOS 0.98. My own experience from today showed that the GENERIC -current stock kernel will fail at least ltaer on in the process when glxpcib detects the AMD5536 PCI bridge and tries to start the hardware timer which is then assigned to the watchdog. Upgrading the BIOS to the latest version 0.99 solved the problem for me just two hours ago, see my three consecutive posts from earlier today. Regards, Rolf
Re: GENERIC -current kernel requires modification to boot on ALIX
On Jan 12, 2008 5:00 PM, Rolf Sommerhalder <[EMAIL PROTECTED]> wrote: > The problem seems to occurs while the function glxpcib_attach() in > src/sys/arch/i386/pci/glxpcib.c attaches the watchdog timer. If I > comment out the lines Upgrading the ALIX firmware from 0.98 to the latest BIOS v0.99 solved the problem! My appologies for the noise. But maybe the archive may preventing others to pull their hair out in the future :-) Also, note that it took me quite a while to figure out why my attempts to upgrade via the Xmodem procedure failed. According to the readme in the firmware .zip archive, PC Engines has not ported the Xmodem flash upgrade option yet. Thus you need to image a CF card with FreeDOS, as PC Engine's Web page mentions, boot ALIX under FreeDOS, and then finally run sb.com which updates the firmware. Good luck, Rolf
Re: GENERIC -current kernel requires modification to boot on ALIX
On Jan 12, 2008 1:11 PM, Rolf Sommerhalder <[EMAIL PROTECTED]> wrote: > I do not yet understand if the problem comes from the timer / watchdog > / GPIO which glxpcib activates, or if I should try to do a BIOS > upgrade of the ALIX board to the latest revision. The problem seems to occurs while the function glxpcib_attach() in src/sys/arch/i386/pci/glxpcib.c attaches the watchdog timer. If I comment out the lines /* count in seconds (as upper level desires) */ // bus_space_write_2(sc->sc_iot, sc->sc_ioh, AMD5536_MFGPT0_SETUP, // AMD5536_MFGPT_CNT_EN | AMD5536_MFGPT_CMP2EV | // AMD5536_MFGPT_CMP2 | AMD5536_MFGPT_DIV_MASK); // wdog_register(sc, glxpcib_wdogctl_cb); printf(", watchdog"); then all is well, except that the watchdog does not get its hardware time, of course. The GPIO part attaches fine and I can toggle LEDs using gpioctl. Only commenting out the wdog_register() call, but leaving the call to bus_space_write_2() active makes boot still stop. So the problems appears to be with the call to bus_space_write_2(). Who is familiar with this function and the AMD5536? Thanks, Rolf
GENERIC -current kernel requires modification to boot on ALIX
Hello, I found that GENERIC -current (from latest snapshot) fails to boot on ALIX (see A) below), whereas the same kernel boots fine on WRAP. For my tests, I simply swap the same 1GB CF card, from the WRAP to ALIX on which I installed OpenBSD from the latest snapshots. After disabling 'pciglxb' in the kernel however, the same CF card boots fine on the ALIX (see B) below) as well as on WRAP: config -ef /bsd disable glxpcib quit reboot Earlier, I have made the same observation while building a custom kernel using the flashboot enviroment. As a result, no watchdog time is available, for example. I found this while moving my SOHO firewall cluster from two old Nokia IP120 which boot OpenBSD from harddisks to two ALIX boards from PC Engines which boot off solid-state CF cards. In order to preserve the CF card, I have modified it so that /tmp, /var and /dev are mounted read-write to RAM (mfs), and the remaining file systems are mounted read-only (e.g. running from CF card). I do not yet understand if the problem comes from the timer / watchdog / GPIO which glxpcib activates, or if I should try to do a BIOS upgrade of the ALIX board to the latest revision. Has anyone experience the same? How did you solve it? Any suggestions what I should try next? Thanks, Rolf A) Console output when booting unmodified GENERIC -current kernel PC Engines ALIX.2 v0.98 640 KB Base Memory 261120 KB Extended Memory 01F0 Master 848A SanDisk SDCFH-1024 Phys C/H/S 1986/16/63 Log C/H/S 993/32/63 Using drive 0, partition 3; Loading;... probing: pc0 com0 pci mem[640K 255M a20=on] disk: hd0 >> OpenBSD/i386 BOOT 3.01 - com0: 38400 baud switching console to com0 [ using 593308 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2008 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 4.2-current (GENERIC) #647: Fri Jan 11 02:06:06 MST 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC RTC BIOS diagnostic error 80 cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 499 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX real mem = 268009472 (255MB) avail mem = 251240448 (239MB) RTC BIOS diagnostic error 80 mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 10/31/07, BIOS32 rev. 0 @ 0xfcdda acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xe/0xb000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31 glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES vr0 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10, address 00:0d:b9:12:6c:10 ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 10 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address 00:0d:b9:12:6c:11 ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr2 at pci0 dev 11 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12, address 00:0d:b9:12:6c:12 ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 ral0 at pci0 dev 12 function 0 "Ralink RT2561" rev 0x00: irq 9, address 00:08:a1:9c:32:c4 ral0: MAC/BBP RT2661B, RF RT2527 glxpcib0 at pci0 dev 15 function 0 "AMD CS5536 ISA" rev 0x03: rev 0, 32-bit 3579545Hz timer B) dmesg after modification of kernel by running 'config -ef /bsd', 'disable pciglxb', 'quit' [EMAIL PROTECTED]:root]# dmesg OpenBSD 4.2-current (GENERIC) #647: Fri Jan 11 02:06:06 MST 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 499 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX real mem = 268009472 (255MB) avail mem = 251240448 (239MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 10/31/07, BIOS32 rev. 0 @ 0xfcdda acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xe/0xb000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31 glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES vr0 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10, address 00:0d:b9:12:6c:10 ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pc
Re: Running dhclient on CARP interfaces
The really cool combination of CARP and ifstated enabled a nice work-around. The attached ifstated.conf works great in my active-passive firewall cluster setup. At least it survived all violent testing conducted over the past few hours. But it still needs to prove itself in the longer term. Actually, this solution does more than simply running dhclient on CARP would do. With one exception: I could not you figure out how to transition from a passive-active firewall cluster to an active-active configuration without having a CARP interface with a dynamic IP address that connects to the ISP. Therefore, I would still be interested in getting dhclient to work on a CARP interface. Also, I welcome your feedback about the solution outlined below. Thanks, Rolf A few remarks on the ifstated.conf shown below: a) vlan11 is a VLAN bound to the same NIC as carp12. dhclient is run on vlan11 (Actually, carp12 is bound to vlan11, which in turn is bound to the physical NIC liniking to upstream).. dhclient assigns the dynamic IP address to vlan11 whenever a node of a cluster is in master state. Nodes in backup state kill dhclient, delete the dynamic IP address from their vlan11, change the default route from the ISP router to the firewall's virtual cluster address (which is here carp100 = 10.0.0.1) and kill and restart some daemons with some modified parameters: - dhcpd runs only on the master node; - ntpd pn the backup node(s) get their time reference from the master node, to avoid doubling the load on external time servers; - only one ez-ipupdate instance running on the master node takes care of updating my dynamic DNS service provider; b) carp12 is a CARP interface on the same NIC that connects to the ISP modem. carp12 is bound to a fixed IP address. The ifstated configuration below uses it just for detecting the state(-changes) of the upstream link, e.g. it is not the CARP interface I would like to run dhclient on (which would be carp11). c) You can replace vlan11 by any other vlan, or by a phsyical interface, such as fxp2 for example. You can replace carp12 by any other CARP interface as long as it is a reliable state indicator of each node in the cluster. [EMAIL PROTECTED]:root]# cat /etc/ifstated.conf init-state startState carpUp = "carp12.link.up" carpDown = "!carp12.link.up" state startState { if $carpUp set-state masterState if $carpDown set-state backupState } state masterState { init { # assert services are killed to avoid duplicates in case the were still up, # for ex. after a restart of ifstated restart while masterState was never left run "/usr/bin/pkill -9 ntpd" run "/usr/bin/pkill -9 dhcpd" run "/usr/bin/pkill -9 ez-ipupdate" run "/usr/bin/pkill -9 dhclient" run "/sbin/dhclient vlan11" run "/usr/local/bin/ez-ipupdate -c /etc/ez-ipupdate.conf" run "/usr/sbin/dhcpd" #run "/usr/sbin/ntpd -s -f /etc/ntpd_masterState.conf" run "/usr/sbin/ntpd -f /etc/ntpd_masterState.conf" } if $carpDown set-state backupState } state backupState { init { run "/usr/bin/pkill -9 ntpd" run "/usr/bin/pkill -9 dhcpd" run "/usr/bin/pkill -9 ez-ipupdate" run "/usr/bin/pkill -9 dhclient" run "/sbin/ifconfig vlan11 delete" run "/sbin/route change default 10.0.0.1" #run "/usr/sbin/ntpd -s -f /etc/ntpd_backupState.conf" run "/usr/sbin/ntpd -f /etc/ntpd_backupState.conf" } if $carpUp set-state masterState }
Running dhclient on CARP interfaces
y problem http://undeadly.org/cgi?action=article&sid=20071012140725&pid=2 But, so far, I was unable to locate it. Were those scripts ever published later? Is there a specific reason why dhclient does run on CARP interface as I exepected? Or, was it not implemented because there is niot really a need for this? Are there simply better solutions, for example using ifstated? Otherwise, OpenBSD performs amazingly well in this SOHO setup which uses two recycled old Nokia IP120 boxes (scrapped IPSO/Checkpoint FW-1 for OpenBSD) for the firewall cluster at the inner stage, and two WRAP for the firewall cluster at the outer stage. Thanks for any suggestions and pointers, Rolf
Re: How to track down a suspected memory leak?
On Nov 25, 2007 5:22 PM, David Higgs <[EMAIL PROTECTED]> wrote: > Is this possibly the same memory leak mentioned below? > > http://marc.info/?l=openbsd-misc&m=119572453509542&w=2 Thanks for your pointer! Indeed, this patch/errata appears to have sqashed the memory leak. A patched kernel did not loose memory since Monday anymore. Thanks again, Rolf
IP over Simulated Radio/Satellite Channels
In an effort to port a Performance Enhancing Proxy (PEP, see scps.org) to OpenBSD, I am looking at ways to simulate radio channels at IP level with loss rate, delay and jitter. Has anyone worked on, for example, extending ALTQ to add delay and/or jitter capability to OpenBSD? Would I waste my time diving into the source of ALTQ? Two years back, I wrote an extension plugin for m0n0wall.ch which uses ipfw and dummynet in FreeBSD for traffic shaping. Actually, dummynet started off as an IP channel simulator that provides delay and jitter options besides loss rate, and then was also used for shaping/queuing. A search of the archives revealed that others asked also about extended IP channel simulation in OpenBSD. But I could not find anything ready to use yet. OpenBSD's IP stack parameter setting for high bandwidth-delay satellite channels were apparently tested using externally supplied simulation data. Apparently, others also worked on porting the SCPS (TP?) PEP to OpenBSD, but I am unclear if they ever succeeded to make it work, and if they published their work. I am grateful for any pointers towards IP channel simulation and/or PEPs such as SCPS TP in OpenBSD. Thanks, Rolf
Re: How to track down a suspected memory leak?
On Nov 25, 2007 5:22 PM, David Higgs <[EMAIL PROTECTED]> wrote: > > Is this possibly the same memory leak mentioned below? > > http://marc.info/?l=openbsd-misc&m=119572453509542&w=2 Thanks David for this pointer. It may very well be the same issue. Even though the two bridged interfaces are em(4) (1 Gb/s), the Out-of-Band Management (OOBM) interface is fxp(4) that carries two VLANs, one for pfsync(4), and one for command&control/monitoring. Interestingly, I observe memory depletion at the same rate on both nodes of these active-passive filtering bridge clusters (both the sparc64 and i386), e.g. free memory on the passive bridge depletes at the same rate as on the one that is active. This may hint that the problem is rather with the fxp(4) than with the em(4) which are bridged. Unless it is somehow related to Rapid Spanning Tree (RSTP) which is running on both the internal and external em(4)s on both the active and the passive node. Maybe it's worth mentioning that on the previous sparc64 platforms (Sun Blade 100), where I observed slow memory depletion first, the bridging was between two ports of a quad hme(4) NIC, and the OOBM was on a third port of the same quad NIC. Still, I will given Henning's patch a try, while waiting for results of the instrumentation with 'vmstat -m', as suggested by the previous responder. Thanks again, Rolf [EMAIL PROTECTED]:home]# ifconfig lo0: flags=8049 mtu 33208 groups: lo inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 em0: flags=8943 mtu 1500 lladdr 00:10:f3:0c:fa:d6 description: brExt_InternetEx media: Ethernet autoselect (1000baseT full-duplex) status: active inet6 fe80::210:f3ff:fe0c:fad6%em0 prefixlen 64 scopeid 0x1 em1: flags=8943 mtu 1500 lladdr 00:10:f3:0c:fa:d7 description: brInt_InternetInt media: Ethernet autoselect (1000baseT full-duplex) status: active inet6 fe80::210:f3ff:fe0c:fad7%em1 prefixlen 64 scopeid 0x2 fxp0: flags=8802 mtu 1500 lladdr 00:10:f3:0c:fa:d8 media: Ethernet autoselect (none) status: no carrier fxp1: flags=8843 mtu 1500 lladdr 00:10:f3:0c:fa:d9 description: VLAN trunk OOBMgtExt, brSync media: Ethernet autoselect (100baseTX full-duplex) status: active inet6 fe80::210:f3ff:fe0c:fad9%fxp1 prefixlen 64 scopeid 0x4 enc0: flags=0<> mtu 1536 vlan21: flags=8843 mtu 1500 lladdr 00:10:f3:0c:fa:d9 description: brSync vlan: 21 priority: 0 parent interface: fxp1 groups: vlan inet6 fe80::210:f3ff:fe0c:fad9%vlan21 prefixlen 64 scopeid 0x7 inet 192.168.7.13 netmask 0xff00 broadcast 192.168.7.255 vlan71: flags=8843 mtu 1500 lladdr 00:10:f3:0c:fa:d9 description: OOBMgtExt vlan: 71 priority: 0 parent interface: fxp1 groups: vlan egress inet6 fe80::210:f3ff:fe0c:fad9%vlan71 prefixlen 64 scopeid 0x8 inet 172.16.71.13 netmask 0xff00 broadcast 172.16.71.255 pfsync0: flags=41 mtu 1460 description: pfSync pfsync: syncdev: vlan21 syncpeer: 224.0.0.240 maxupd: 128 groups: carp pfsync bridge0: flags=41 mtu 1500 groups: bridge pflog0: flags=141 mtu 33208 groups: pflog [EMAIL PROTECTED]:home]# bridge0: flags=41 priority 28672 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp em1 flags=cb port 2 ifpriority 128 ifcost 2 forwarding role designated em0 flags=cf port 1 ifpriority 128 ifcost 2 forwarding role root Addresses (max cache: 100, timeout: 240): 00:00:5e:00:01:0b em1 1 flags=0<> 00:11:20:2f:09:54 em0 1 flags=0<> 00:1d:46:97:5f:0d em1 1 flags=0<> 00:1d:46:97:5f:03 em0 1 flags=0<> [EMAIL PROTECTED]:home]# [EMAIL PROTECTED]:home]# dmesg OpenBSD 4.2-current (GENERIC) #476: Fri Nov 2 14:41:26 MDT 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) 4 CPU 2.80GHz ("GenuineIntel" 686-class) 2.80 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,CNXT-ID,xTPR real mem = 1072197632 (1022MB) avail mem = 1028968448 (981MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 06/29/06, BIOS32 rev. 0 @ 0xfb250, SMBIOS rev. 2.2 @ 0xf0800 (34 entries) bios0: vendor Phoenix Technologies, LTD version "6.00 PG" date 06/29/2006 apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown pcibios0 at bios0: rev 2.1 @ 0xf/0xdf84 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdea0/208 (11 entries) pcibios0: PCI Exclusive IRQs: 5 10 11 12 pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82371SB ISA" rev 0x00) pcibios0: PCI b
How to track down a suspected memory leak?
Hello list, I am looking for suggestions how to identify the source(s) of what appears to be a memory leak of approx. 10 MByte/day on a clustered pair of filtering bridges. These bridges are running i386 -current snapshot from Nov 2nd. They form outer, Internet-facing stage of a two stage firewall in an enterprise setup. Before we received two new i386 servers, the same setup was running on two sparc64 servers with a snapshot about one month old. Back then, I observed the same steady decrease of memory, graphing trends using net-snmp and Cacti. Those old sparc64 servers only had 192 MByte of RAM, they ran out of memory and stopped working after 10 days or so. As I had some difficulties to get net-snmp to run at all on sparc64 (see patch posted to this list earlier), I was hoping to get away from this apparent memory leak once I migrate to to newer i386 servers. After the migration from sparc64 to i386, indeed the memory consumed during the first few days remained constant. Thereafter however, the steady decrease of free memory also started to appear on the i386 much like with the sparc64. I disabled all SNMP GET operations for a few hours, just to see if the leak might be caused by net-snmp, but the leakage continues during this time too. Staring at the output of 'systat vmstat' etc. did not help either. The pragmatic work-around for the moment is cron job that reboots each of the cluster nodes once a week. There is is enough headroom with 1 GByte of RAM on these i386 servers. The two cluster nodes reboot at different times, so the service is interrupted only for a few seconds until rapid spanning tree completes fail-over. At the moment, on a much smaller scale, I replicate such a two stage clustered firewall setup for home use. based on OpenBSD flashboot, WRAP / ALIX boards from PCengines and surplus Nokia IP120s which I converted to OpenBSD. Also because the WRAPs have only 128 MByte of RAM, I very much like to get to the root cause of that apparent memory leak in my clustered filtering bridge configuration. I am grateful for any hints and suggestions how to track it down. Thanks, Rolf
Re: hoststated(8): DNS Relay uses unexpected source IP address
On Nov 19, 2007 6:35 PM, Reyk Floeter <[EMAIL PROTECTED]> wrote: > please try to configure the following: ... > so the proposed solution is to always use "listen on 0.0.0.0 port 53" > with DNS relays for now. Your proposal indeed solves the problem in my multi-homed setup, and makes my work-around with source NAT rule obsolete! Thank you very much. In the long run, would it be feasible to extend relay_udp_bind() so that its binds to the IP address of the interface to which it will relay those DNS UDP packets (while also observing the default route)? Could this eliminate the implicit use of "spoofed" sender IP addresses by the DNS relay on multi-homed hosts, without adding any knobs? Rolf
Re: hoststated(8): DNS Relay uses unexpected source IP address
On Nov 18, 2007 8:04 AM, Theo de Raadt <[EMAIL PROTECTED]> wrote: > Oh, one does that by calling bind() beforehands, with the specific > local address one which uses use, instead of 0.0.0.0. With udp this Thanks Theo for your hint. I look into this in the context of hoststated. What still puzzles me is that my multi-homed server sends out UDP packets on interface fxp2=10.1.1.31 with source IP address of another interface, e.g. fxp3=10.2.2.31. Therefore, I'll take a look at bind(2) and sendto(2) now, maybe this helps to solve my confusion (poured too much Kirsch into the cheese fondue last night ;-). By the way, googling with "Set source address for UDP packets from multihomed server" brought up some interesting discussions in other contexts, such as OpenVPN, bind or ntpd.
Re: hoststated(8): DNS Relay uses unexpected source IP address
On Nov 17, 2007 4:58 PM, Rolf Sommerhalder <[EMAIL PROTECTED]> wrote: > Still, I am unsure if the DNS/UDP relay actually behaves correctly, > and if this work-around does make sense. After a deep dive into the sources of hoststated, my current understanding is that this is not a problem caused by hoststated itself, but rather how the underlaying IP stack determines the source IP address of a UDP packet when the server is multi-homed. relay_dns_request() in src/usr.sbin/hoststated/relay_udp.c calls sendto() with the correct destination IP. However, the source IP address can not be passed to sendto(). Are there facilities to set the source address for UDP packets sent from a multi-homed server?
Re: hoststated(8): DNS Relay uses unexpected source IP address
On Nov 17, 2007 4:01 PM, Rolf Sommerhalder <[EMAIL PROTECTED]> wrote: > This unexpected behaviuor of the DNS/UDP relay then causes routing > problems as the "white" server is by default unaware of a route for > the source address (yellow.fxp3). So DNS responses from "white" do not > get routed back to "yellow". Of course, I could add a route on "white" > as a workaround. But it would be more elegant if the DNS/UDP relay > would behave the same way as the TCP relays do. In order to figure out As an alternate work-around, I just tried to insert a source NAT rule in /etc/pf.conf on "yellow", which masks/solves the routing problem locally on the reverse proxy machine: [EMAIL PROTECTED]:etc]# cat /etc/pf.conf # source NAT for routing back from white for DNS only nat log on fxp2 from 10.2.2.31 to 10.1.1.30 port 53 -> (fxp2) Probably, I should add at least "static-port" to the NAT rule above in order to prevent "white" from modifying the source port 53 (see tcpdump below). Still, I am unsure if the DNS/UDP relay actually behaves correctly, and if this work-around does make sense. Rolf A) DNS/UDP Example reloaded, now with source NAT on "yellow" Output of "hoststated -v -d" after issuing a DNS lookup on "orange": relay_dns_log: session 1: request id 0xde7 flags 0x1:0x0 qd 1 an 0 ns 0 ar 0 relay_dns_log: session 1: response id 0x9cc flags 0x85:0x80 qd 1 an 1 ns 1 ar 0 relay dnsRelay, session 1 (1 active), 10.2.2.32 -> 10.1.1.30:53, session closed hostated listens on the right NIC fxp3: [EMAIL PROTECTED]:root]# tcpdump -i fxp3 -n tcpdump: listening on fxp3, link-type EN10MB 16:45:19.718243 arp who-has 10.2.2.31 tell 10.2.2.32 16:45:19.718274 arp reply 10.2.2.31 is-at 00:10:f3:0d:32:70 16:45:19.718461 10.2.2.32.32768 > 10.2.2.31.53: 3559+ A? orange. (36) (DF) 16:45:19.720859 10.2.2.31.53 > 10.2.2.32.32768: 3559* 1/1/0 A 172.16.70.32 (69) hostated passes on the proxied requets to the left NIC fxp2, using the source address (fxp2)=10.1.1.31, as forced by source NAT: [EMAIL PROTECTED]:root]# tcpdump -i fxp2 -n tcpdump: listening on fxp2, link-type EN10MB 16:48:57.815366 10.1.1.31.51245 > 10.1.1.30.53: 65223+ A? orange. (36) 16:48:57.816452 10.1.1.30.53 > 10.1.1.31.51245: 65223* 1/1/0 A 172.16.70.32 (69)
hoststated(8): DNS Relay uses unexpected source IP address
Hello list, using the excellent hoststated(8), I have build a reverse proxy "yellow" with the snapshot from around November 3rd on an i386 box which is connected to "white" (another OpenBSD host) on the left via fxp2, and to "orange" (a Linux host) to its right via fxp3. (white.fxp3) and (fxp2.yellow) are in subnet 10.1.1.0/24, whereas (yellow.fxp3) and (eth0.orange) are in 10.2.2.0(24. ...---tun0.white.fxp3---fxp2.yellow.fxp3---eth0.orange hoststated on "yellow" has several relays that listen on various ports on its right (fxp3) and relays them via (fxp2) to left to "white", such as for ex. (fxp3):6000/tcp (for X11 relaying using the generic TCP relay), or (fxp3):53/udp (for DNS relaying using the DNS/UDP relay). When "orange" issues X11 connections from its (eth0.orange) to (yellow.fxp3), "yellow" relays those connections perfectly to "white" using (fxp2.yellow) as source and (white.fxp3) as destination addresses. This also works fine for all other TCP relays that I tried. However, the UDP/DNS relay behaves slightly different. It relays DNS request to the left with (yellow.fxp3) (note: fxpTHREE) as source address, unlike TCP relays and not as I had expected, with (fxp2.yellow) (note: fxpTWO) as source address. Yet, I am not sure if this is intended behaviour, or a bug that surfaces with my particular use of hoststated to insulating two subnetworks. This unexpected behaviuor of the DNS/UDP relay then causes routing problems as the "white" server is by default unaware of a route for the source address (yellow.fxp3). So DNS responses from "white" do not get routed back to "yellow". Of course, I could add a route on "white" as a workaround. But it would be more elegant if the DNS/UDP relay would behave the same way as the TCP relays do. In order to figure out if I misunderstand this, I have started to read the source of relay_dns_request() in /src/usr.sbin/hoststated/relay_udp.c of -current. I am grateful for any hints with the cluestick. Also, I am happy to provide more info, or to apply and test patches. Thanks, Rolf P.S. For those who wonder what this is all about, "orange" is an application server in a secure zone, and we need to get data across two security boundaries safely to "white", which is in fact a VPN tunnel endpoint in a less secure zone. The "---" in the figure above are actually large networks that are separated by firewalls. However, in my lab setup these are simple cross-over Ethernet cables :-) [EMAIL PROTECTED]:etc]# dmesg OpenBSD 4.2-current (GENERIC) #476: Fri Nov 2 14:41:26 MDT 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Mobile Intel(R) Celeron(TM) CPU 650MHz ("GenuineIntel" 686-class) 647 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real mem = 519602176 (495MB) avail mem = 494592000 (471MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/30/04, BIOS32 rev. 0 @ 0xfb470, SMBIOS rev. 2.2 @ 0xf0800 (38 entries) bios0: vendor Phoenix Technologies, LTD version "6.00 PG" date 11/30/2004 bios0: VIA Technologies, Inc. CLE266-8233/5 [EMAIL PROTECTED]:etc]# ifconfig lo0: flags=8049 mtu 33208 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 inet 127.0.0.1 netmask 0xff00 fxp0: flags=8843 mtu 1500 lladdr 00:10:f3:0d:32:6d description: OOBM groups: egress media: Ethernet autoselect (100baseTX full-duplex) status: active inet6 fe80::210:f3ff:fe0d:326d%fxp0 prefixlen 64 scopeid 0x1 inet 172.16.70.31 netmask 0xff00 broadcast 172.16.70.255 fxp1: flags=8802 mtu 1500 lladdr 00:10:f3:0d:32:6e media: Ethernet autoselect (none) status: no carrier fxp2: flags=8943 mtu 1500 lladdr 00:10:f3:0d:32:6f description: to white/fxp3 media: Ethernet autoselect (100baseTX full-duplex) status: active inet6 fe80::210:f3ff:fe0d:326f%fxp2 prefixlen 64 scopeid 0x3 inet 10.1.1.31 netmask 0xff00 broadcast 10.1.1.255 fxp3: flags=8843 mtu 1500 lladdr 00:10:f3:0d:32:70 description: to orange/eth1 media: Ethernet autoselect (100baseTX full-duplex) status: active inet6 fe80::210:f3ff:fe0d:3270%fxp3 prefixlen 64 scopeid 0x4 inet 10.2.2.31 netmask 0xff00 broadcast 10.2.2.255 enc0: flags=0<> mtu 1536 pflog0: flags=141 mtu 33208 groups: pflog [EMAIL PROTECTED]:etc]# [EMAIL PROTECTED]:etc]# cat /etc/hoststated.conf # Macros # proxies listen on yellow="10.2.2.31" # and relay traffic to VPN Tunnel endpoint white="10.1.1.30" sshHost="10.2.90.3" dnsHost="10.2.90.1" x11Host="10.2.90.3" # Global Options log updates prefork 1 interval 10 # run
Re: iSCSI
> A quick Google search shows some people having success in porting NetBSD's > iSCSI to OpenBSD. > >perhaps Marco will chime in on this. > >diana If testers for an iSCSI initiator on OpenBSD should be needed, I am glad to help out. I run i386.mp-current and sparc64-current on servers that can access two iSCSI IP arrays from EqualLogic (3 and 7 TB), and a homebrew iSCSI target array (2.3 TB) running FreeNAS, over GigEthernet with Jumbo frame and (partial) multipath I/O support.. Rolf
hoststated: throws "Undefined error: 0" in i386 -current
This simple configuration file for hoststated below is syntactically correct (and semantically, too), however apparently only if its file mode bits are 600 (which makes sense). Somehow, I ended up with mode bits being set to 644, upon which hoststated refused to accept it but throws an "Undefined error: 0". It took me a while to figure out that it occurs due to mode bits being set somewhat too liberal because the error does not provide any hint. Also, I only upgraded to -current last night, and the same configuration file was accepted with mode bits 644 by the latest available snapshot without complaint before upgrading. Actually, I just tried 'hoststated -d -f /etc/hoststated.rs' which throuws the same error, but only after hinting about the mode bits being wrong. So it might be helpful to just add the same hint output to the -n option as well. I had no opportunity to crosscheck on sparc64 -current yet, or to propose a small diff, sorry for that. Thanks, Rolf [EMAIL PROTECTED]:root]# cat /etc/hoststated.rs extAddr="1.2.3.4" table rsHosts { real port http check icmp host 10.2.90.3 } service rsService { virtual host $extAddr port 80 interface carp11 table rsHosts } [EMAIL PROTECTED]:root]# ls -al /etc/hoststated.rs -rw--- 1 root wheel 170 Oct 18 20:42 /etc/hoststated.rs [EMAIL PROTECTED]:root]# hoststated -n -f /etc/hoststated.rs configuration OK [EMAIL PROTECTED]:root]# chmod 644 /etc/hoststated.rs [EMAIL PROTECTED]:root]# hoststated -n -f /etc/hoststated.rs hoststated: /etc/hoststated.rs: Undefined error: 0 [EMAIL PROTECTED]:root]# hoststated -d -f /etc/hoststated.rs /etc/hoststated.rs: group/world readable/writeable hoststated: /etc/hoststated.rs: Undefined error: 0 [EMAIL PROTECTED]:root]# dmesg OpenBSD 4.2-current (GENERIC.MP) #5: Thu Oct 18 06:00:11 CEST 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Dual-Core AMD Opteron(tm) Processor 2210 ("AuthenticAMD" 686-class, 1024KB L2 cache) 1.80 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16 real mem = 2146979840 (2047MB) avail mem = 2068201472 (1972MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 04/11/07, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.3 @ 0xfbd50 (70 entries) bios0: vendor American Megatrends Inc. version "0ABJX039" date 04/11/2007 bios0: Sun Microsystems Sun Fire X4100 M2 ...
dmesg of i386 on Virtual Iron 4.0.5
Virtual Iron (VI) is a commercial virtualisation product based on Xen 3.1 dom0 which boots unmodified bsd.rd i386 and installs in a domU. As you can see from the dmesg below, it occasionally complains about timeouts on re0, and the virtual console gets cluttered in the later stages of the install. Other than that, login into sshd on the virtual OpenBSD box works, although I have not done exhaustive tests regarding stability nor performance. So far, I had no success in booting bsd.mp, however. Even after set image bsd.mp boot -c disable apm enable acpi exit bsd.mp stops after printing "nvram: invalid checksum". When leaving the defaults (e.g. apm enabled and acpi disabled), bsd.mp stops just after printing this, followed by "apm0: APM system defaults failed: unknown error code? (83)" "apm0: disconnected" If someone is interested in having a closer look, then I will try to make transcripts from the virtual console (or screenshots). VI 4.0 was released last week. Even if it officially supports only a handful of selected guest OS as of now, and there no VI Tools available for OpenBSD (yet - source is available), I gave it a try on virtualized Sun Fire X4600 M2 servers with iSCSI IP SAN arrays from EqualLogic in a pre-prod lab. VI is an interesting alternative to ESX from VMware, and it also competes with XenSource. Regards, Rolf # dmesg OpenBSD 4.2-current (GENERIC) #405: Thu Sep 13 16:06:09 MDT 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Dual-Core AMD Opteron(tm) Processor 8220 ("AuthenticAMD" 686-class, 1024KB L2 cache) 2.81 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16 real mem = 536416256 (511MB) avail mem = 510992384 (487MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 06/23/99, BIOS32 rev. 0 @ 0xfa3b0, SMBIOS rev. 2.4 @ 0xe901f (11 entries) bios0: vendor Xen version "3.1-070908" bios0: Xen HVM domU apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 30102 dobusy 0 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xf/0x0 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfa650/128 (6 entries) pcibios0: PCI Interrupt Router at 000:01:0 ("Intel 82371SB ISA" rev 0x00) pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xc/0x8000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 9536MB, 19529728 sectors wd0(pciide0:0:0): using PIO mode 0, DMA mode 2 atapiscsi0 at pciide0 channel 1 drive 1 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: SCSI0 5/cdrom removable cd0(pciide0:1:1): using PIO mode 0, DMA mode 2 piixpm0 at pci0 dev 1 function 2 "Intel 82371AB Power" rev 0x01: SMBus disabled vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) unknown vendor 0x5853 product 0x0001 (class undefined unknown subclass 0x80, rev 0x01) at pci0 dev 3 function 0 not configured re0 at pci0 dev 4 function 0 "Realtek 8139" rev 0x20: RTL8139C+ (0x7480), irq 5, address 00:0f:4b:16:fd:0f rlphy0 at re0 phy 0: RTL internal PHY isa0 at pcib0 isadma0 at isa0 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 pmsi0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pmsi0 mux 0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: density unknown fd1 at fdc0 drive 1: density unknown biomask efdd netmask effd ttymask pctr: user-level cycle counter enabled mtrr: Pentium Pro MTRR support nvram: invalid checksum dkcsum: wd0 matches BIOS drive 0x80 root on wd0a swap on wd0b dump on wd0b clock: unknown CMOS layout re0: watchdog timeout re0: watchdog timeout re0: watchdog timeout re0: watchdog timeout re0: watchdog timeout #
Re: unstable and multiple reboot for 4.2 on Sun X4100 M2 with ACPI enable on AMD64 bsd.mp with SAS RAID 1 setup.
The latest snapshot (13. Sept). of amd64 bsd.mp with ACPI enabled runs stable on two X4100 M2 which are identically configured (single SAS disk only, no RAID-1 yet, with current BIOS/SP/SAS Firmware from Sun). As Daniel already observed with a snapshot that is two days older, booting is much faster than with previous shapshots, no long dalys around IPMI startup. Keeping an eye on stability over the next few days while putting this firewall cluster into pre-production (it runs pf, pfsync, a bunch of VLANs with CARP on almost every VLAN, named, sendmail, OpenVPN, Squid, and some other application-level gateway/proxies). Next wekk, I also intend to insert a second SAS disk and add RAID-1. # dmesg OpenBSD 4.2-current (GENERIC.MP) #1388: Thu Sep 13 14:31:22 MDT 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2147012608 (2047MB) avail mem = 2073640960 (1977MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xfbd50 (70 entries) bios0: vendor American Megatrends Inc. version "0ABJX039" date 04/11/2007 bios0: Sun Microsystems Sun Fire X4100 M2 acpi0 at mainbus0: rev 2 acpi0: tables DSDT FACP APIC SPCR SLIT OEMB HPET IPET SRAT SSDT acpitimer at acpi0 not configured acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Dual-Core AMD Opteron(tm) Processor 2210, 1795.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,CX16,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 2210, 1795.23 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,CX16,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 ioapic0 at mainbus0 apid 15 pa 0xfec0, version 11, 24 pins ioapic1 at mainbus0 apid 16 pa 0xfeafd000, version 11, 7 pins ioapic1: misconfigured as apic 0, can't remap to apid 16 ioapic2 at mainbus0 apid 17 pa 0xfeafc000, version 11, 7 pins ioapic2: misconfigured as apic 1, can't remap to apid 17 ioapic3 at mainbus0 apid 14 pa 0xfeaff000, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus 4 (P0P4) acpiprt3 at acpi0: bus 5 (P0P5) acpiprt4 at acpi0: bus 255 (PCIB) acpiprt5 at acpi0: bus -1 (POGA) acpiprt6 at acpi0: bus -1 (POGB) acpiprt7 at acpi0: bus -1 (BR5D) acpiprt8 at acpi0: bus -1 (BR5E) acpiprt9 at acpi0: bus 128 (PCIC) acpiprt10 at acpi0: bus 133 (POGA) acpiprt11 at acpi0: bus 134 (POGB) acpicpu at acpi0 not configured acpicpu at acpi0 not configured acpicpu at acpi0 not configured acpicpu at acpi0 not configured acpibtn at acpi0 not configured ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca4/2 spacing 1 pci0 at mainbus0 bus 0: configuration mode 1 "NVIDIA nForce4 DDR" rev 0xa3 at pci0 dev 0 function 0 not configured pcib0 at pci0 dev 1 function 0 "NVIDIA nForce4 ISA" rev 0xa3 nviic0 at pci0 dev 1 function 1 "NVIDIA nForce4 SMBus" rev 0xa2 iic0 at nviic0: disabled to avoid ipmi0 interactions iic1 at nviic0: disabled to avoid ipmi0 interactions ohci0 at pci0 dev 2 function 0 "NVIDIA nForce4 USB" rev 0xa2: apic 15 int 11 (irq 11), version 1.0, legacy support ehci0 at pci0 dev 2 function 1 "NVIDIA nForce4 USB" rev 0xa3: apic 15 int 5 (irq 5) usb0 at ehci0: USB revision 2.0 uhub0 at usb0: "NVIDIA EHCI root hub", rev 2.00/1.00, addr 1 pciide0 at pci0 dev 6 function 0 "NVIDIA nForce4 IDE" rev 0xf2: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 disabled (no drives) pciide0: channel 1 ignored (disabled) ppb0 at pci0 dev 9 function 0 "NVIDIA nForce4 PCI-PCI" rev 0xa2 pci1 at ppb0 bus 1 vga1 at pci1 dev 3 function 0 "ATI Rage XL" rev 0x27 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) nfe0 at pci0 dev 10 function 0 "NVIDIA CK804 LAN" rev 0xa3: apic 15 int 15 (irq 15), address 00:14:4f:8e:14:aa eephy0 at nfe0 phy 1: Marvell 88E Gigabit PHY, rev. 2 ppb1 at pci0 dev 11 function 0 "NVIDIA nForce4 PCIE" rev 0xa3 pci2 at ppb1 bus 2 ppb2 at pci0 dev 12 function 0 "NVIDIA nForce4 PCIE" rev 0xa3 pci3 at ppb2 bus 3 ppb3 at pci0 dev 13 function 0 "NVIDIA nForce4 PCIE" rev 0xa3 pci4 at ppb3 bus 4 ppb4 at pci0 dev 14 function 0 "NVIDIA nForce4 PCIE" rev 0xa3 pci5 at ppb4 bus 5 pchb0 at pci0 dev 24 function 0 "AMD AMD64 HyperTransport" rev 0x00pci6 at pchb0 bus 128 "NVI
Re: unstable and multiple reboot for 4.2 on Sun X4100 M2 with ACPI enable on AMD64 bsd.mp with SAS RAID 1 setup.
I did observe similar behaviour on four X4100 M2 as well (two with one socket dual-core, two with two sockets dual-core Opterons) using amd64 bsd.mp snapshots from 23 and 28 Aug.. Currently, amd64 bsd.mp snapshot 28. Aug is running stable on those four servers, although using a single SAS disk without RAID. Several days ago, there was a commit in kernel CVS about delaying start of IPMI which is causing annoying delays at startup of amd64. Eventually, a more recent snapshot becomes available which includes this modification, before I get around to build a -current kernel. Rolf
dmesg amd64.mp with ACPI on Sun Fire X4600 M2
Snapshot 28.Aug. 2007: - amd64.mp with ACPI enabled runs stable, but crashes without ACPI - Interfaces em4, em5 are on an add-on dual-port PCI-Express x4 NIC sold by Sun, manufacturered by Intel. # sysctl hw hw.machine=amd64 hw.model=Dual-Core AMD Opteron(tm) Processor 8220 hw.ncpu=8 hw.byteorder=1234 hw.physmem=3757617152 hw.usermem=3757584384 hw.pagesize=4096 hw.disknames=cd0,sd0,cd1,sd1 hw.diskcount=4 hw.sensors.ipmi0.temp0=38.00 degC (mb.t_amb0), OK hw.sensors.ipmi0.temp1=40.00 degC (mb.t_amb1), OK hw.sensors.ipmi0.temp2=40.00 degC (mb.t_amb2), OK hw.sensors.ipmi0.temp3=24.00 degC (p0.t_amb), OK hw.sensors.ipmi0.temp4=24.00 degC (p1.t_amb), OK hw.sensors.ipmi0.temp5=24.00 degC (p2.t_amb), OK hw.sensors.ipmi0.temp6=24.00 degC (p3.t_amb), OK hw.sensors.ipmi0.temp7=27.00 degC (p0.t_core), OK hw.sensors.ipmi0.temp8=26.00 degC (p1.t_core), OK hw.sensors.ipmi0.temp9=27.00 degC (p2.t_core), OK hw.sensors.ipmi0.temp10=25.00 degC (p3.t_core), OK hw.sensors.ipmi0.fan0=2700 RPM (ft0.fm0.f0.speed), OK hw.sensors.ipmi0.fan1=2700 RPM (ft1.fm0.f0.speed), OK hw.sensors.ipmi0.fan2=2700 RPM (ft2.fm0.f0.speed), OK hw.sensors.ipmi0.fan3=2700 RPM (ft3.fm0.f0.speed), OK hw.sensors.ipmi0.volt0=3.09 VDC (mb.v_bat), OK hw.sensors.ipmi0.volt1=3.30 VDC (mb.v_+3v3aux_r), OK hw.sensors.ipmi0.volt2=3.39 VDC (mb.v_+3v3), OK hw.sensors.ipmi0.volt3=5.07 VDC (mb.v_+5v), OK hw.sensors.ipmi0.volt4=12.16 VDC (mb.v_+12v), OK hw.sensors.ipmi0.volt5=-12.35 VDC (mb.v_-12v), OK hw.sensors.ipmi0.volt6=2.56 VDC (mb.v_+2v5), OK hw.sensors.ipmi0.volt7=1.52 VDC (mb.v_+1v5), OK hw.sensors.ipmi0.volt8=1.27 VDC (mb.v_+1v2), OK hw.sensors.ipmi0.volt9=2.43 VDC (p0.v_+2v5), OK hw.sensors.ipmi0.volt10=1.26 VDC (p0.v_core), OK hw.sensors.ipmi0.volt11=3.22 VDC (p0.v_+3v3aux_r), OK hw.sensors.ipmi0.volt12=11.78 VDC (p0.v_+12v), OK hw.sensors.ipmi0.volt13=1.75 VDC (p0.v_+1v8), OK hw.sensors.ipmi0.volt14=1.22 VDC (p0.v_+1v2), OK hw.sensors.ipmi0.volt15=0.90 VDC (p0.v_+0v9vtt), OK hw.sensors.ipmi0.volt16=2.42 VDC (p1.v_+2v5), OK hw.sensors.ipmi0.volt17=1.26 VDC (p1.v_core), OK hw.sensors.ipmi0.volt18=3.22 VDC (p1.v_+3v3aux_r), OK hw.sensors.ipmi0.volt19=11.78 VDC (p1.v_+12v), OK hw.sensors.ipmi0.volt20=1.74 VDC (p1.v_+1v8), OK hw.sensors.ipmi0.volt21=1.21 VDC (p1.v_+1v2), OK hw.sensors.ipmi0.volt22=0.90 VDC (p1.v_+0v9vtt), OK hw.sensors.ipmi0.volt23=2.42 VDC (p2.v_+2v5), OK hw.sensors.ipmi0.volt24=1.26 VDC (p2.v_core), OK hw.sensors.ipmi0.volt25=3.20 VDC (p2.v_+3v3aux_r), OK hw.sensors.ipmi0.volt26=11.72 VDC (p2.v_+12v), OK hw.sensors.ipmi0.volt27=1.74 VDC (p2.v_+1v8), OK hw.sensors.ipmi0.volt28=1.21 VDC (p2.v_+1v2), OK hw.sensors.ipmi0.volt29=0.89 VDC (p2.v_+0v9vtt), OK hw.sensors.ipmi0.volt30=2.42 VDC (p3.v_+2v5), OK hw.sensors.ipmi0.volt31=1.26 VDC (p3.v_core), OK hw.sensors.ipmi0.volt32=3.22 VDC (p3.v_+3v3aux_r), OK hw.sensors.ipmi0.volt33=11.78 VDC (p3.v_+12v), OK hw.sensors.ipmi0.volt34=1.72 VDC (p3.v_+1v8), OK hw.sensors.ipmi0.volt35=1.22 VDC (p3.v_+1v2), OK hw.sensors.ipmi0.volt36=0.89 VDC (p3.v_+0v9vtt), OK hw.sensors.ipmi0.indicator0=Off (sys.intsw), OK hw.cpuspeed=2800 hw.vendor=Sun Microsystems hw.product=Sun Fire X4600 M2 hw.serialno=0731AN1009 hw.uuid=----00144f794eb1 # # dmesg OpenBSD 4.2 (GENERIC.MP) #1378: Tue Aug 28 10:48:58 MDT 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3757617152 (3583MB) avail mem = 3635957760 (3467MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xfbf20 (83 entries) bios0: vendor American Megatrends Inc. version "080012 " date 04/19/2007 bios0: Sun Microsystems Sun Fire X4600 M2 acpi0 at mainbus0: rev 2 acpi0: tables DSDT FACP APIC SPCR OEMB SRAT HPET IPET SRAT SSDT acpitimer at acpi0 not configured acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Dual-Core AMD Opteron(tm) Processor 8220, 2800.36 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,CX16,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 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Dual-Core AMD Opteron(tm) Processor 8220, 2800.00 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,CX16,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 8220, 2800.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
dmesg amd64-current with ACPI on Sun Fire X4200 M2
Currently, this brand new X4200 M2 only has one of its two sockets equipped with a dual-core Opteron. Some observations: 1. amd64 bsd-snapshot of 28. Aug (single core, without ACPI) appears to run stable; 2. amd64 bsd.mp-.snapshot of 28. Aug (dual core, without ACPI) crashes during/shortly after boot; 3. amd64 bsd.mp-.snapshot of 28. Aug (dual core, ACPI enabled) appears to run stable, although it was running only for a few hours so far. Before installing OpenBSD, the firemares of the BIOS, IPMI and RAID controllers were updated to the current release (v1.2). # sysctl hw hw.machine=amd64 hw.model=Dual-Core AMD Opteron(tm) Processor 2210 hw.ncpu=2 hw.byteorder=1234 hw.physmem=2147012608 hw.usermem=2147004416 hw.pagesize=4096 hw.disknames=sd0,cd0,sd1 hw.diskcount=3 hw.sensors.ipmi0.temp0=33.00 degC (mb.t_amb), OK hw.sensors.ipmi0.temp1=27.00 degC (fp.t_amb), OK hw.sensors.ipmi0.temp2=29.00 degC (pdb.t_amb), OK hw.sensors.ipmi0.temp3=26.00 degC (io.t_amb), OK hw.sensors.ipmi0.temp4=23.00 degC (p0.t_core), OK hw.sensors.ipmi0.fan0=8800 RPM (ft0.fm0.f0.speed), OK hw.sensors.ipmi0.fan1=9300 RPM (ft0.fm2.f0.speed), OK hw.sensors.ipmi0.fan2=9000 RPM (ft0.fm1.f0.speed), OK hw.sensors.ipmi0.fan3=1 RPM (ft1.fm0.f0.speed), OK hw.sensors.ipmi0.fan4=10200 RPM (ft1.fm1.f0.speed), OK hw.sensors.ipmi0.fan5=9500 RPM (ft1.fm2.f0.speed), OK hw.sensors.ipmi0.fan6=8600 RPM (ft0.fm0.f1.speed), OK hw.sensors.ipmi0.fan7=8800 RPM (ft0.fm1.f1.speed), OK hw.sensors.ipmi0.fan8=9200 RPM (ft0.fm2.f1.speed), OK hw.sensors.ipmi0.fan9=9900 RPM (ft1.fm0.f1.speed), OK hw.sensors.ipmi0.fan10=10200 RPM (ft1.fm1.f1.speed), OK hw.sensors.ipmi0.fan11=9100 RPM (ft1.fm2.f1.speed), OK hw.sensors.ipmi0.volt0=2.91 VDC (mb.v_bat), OK hw.sensors.ipmi0.volt1=3.18 VDC (mb.v_+3v3stby), OK hw.sensors.ipmi0.volt2=3.32 VDC (mb.v_+3v3), OK hw.sensors.ipmi0.volt3=5.04 VDC (mb.v_+5v), OK hw.sensors.ipmi0.volt4=12.16 VDC (mb.v_+12v), OK hw.sensors.ipmi0.volt5=-12.42 VDC (mb.v_-12v), OK hw.sensors.ipmi0.volt6=2.56 VDC (mb.v_+2v5core), OK hw.sensors.ipmi0.volt7=1.52 VDC (mb.v_+1v5core), OK hw.sensors.ipmi0.volt8=1.22 VDC (mb.v_+1v2core), OK hw.sensors.ipmi0.volt9=1.33 VDC (p0.v_vdd), OK hw.sensors.ipmi0.volt10=1.84 VDC (p0.v_vddio), OK hw.sensors.ipmi0.volt11=0.91 VDC (p0.v_vtt), OK hw.sensors.ipmi0.indicator0=Off (sys.intsw), OK hw.cpuspeed=1795 hw.vendor=Sun Microsystems hw.product=Sun Fire X4100 M2 hw.serialno=0730AL5C58 hw.uuid=----00144f9ef0a1 # # dmesg OpenBSD 4.2 (GENERIC.MP) #1378: Tue Aug 28 10:48:58 MDT 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2147012608 (2047MB) avail mem = 2073706496 (1977MB) User Kernel Config UKC> enable acpi 266 acpi0 enabled UKC> exit Continuing... mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xfbd50 (70 entries) bios0: vendor American Megatrends Inc. version "0ABJX039" date 04/11/2007 bios0: Sun Microsystems Sun Fire X4100 M2 acpi0 at mainbus0: rev 2 acpi0: tables DSDT FACP APIC SPCR SLIT OEMB HPET IPET SRAT SSDT acpitimer at acpi0 not configured acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Dual-Core AMD Opteron(tm) Processor 2210, 1795.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,CX16,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 2210, 1795.23 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,CX16,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 ioapic0 at mainbus0 apid 15 pa 0xfec0, version 11, 24 pins ioapic1 at mainbus0 apid 16 pa 0xfeafd000, version 11, 7 pins ioapic1: misconfigured as apic 0, can't remap to apid 16 ioapic2 at mainbus0 apid 17 pa 0xfeafc000, version 11, 7 pins ioapic2: misconfigured as apic 1, can't remap to apid 17 ioapic3 at mainbus0 apid 14 pa 0xfeaff000, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus 4 (P0P4) acpiprt3 at acpi0: bus 5 (P0P5) acpiprt4 at acpi0: bus 255 (PCIB) acpiprt5 at acpi0: bus 255 (POGA) acpiprt6 at acpi0: bus 255 (POGB) acpiprt7 at acpi0: bus 255 (BR5D) acpiprt8 at acpi0: bus 255 (BR5E) acpiprt9 at acpi0: bus 128 (PCIC) acpiprt10 at acpi0: bus 133 (POGA) acpiprt11 at acpi0: bus 134 (POGB) acpicpu at acpi0 not configured acpicpu at acpi0 not configured acpicpu at acpi0 not co
dmesg amd64-current on Sun Fire X4600 M2
Thanks for all posts with dmesgs from Sun Fire X2100 / X4100 / X4200 (although most without M2 suffix). They helped us in our purchasing decision of several such servers with M2 suffix. Please find below the dmesg of amd64.mp-current (snapshot 23-Aug-2007) on a Sun Fire X4600 M2 which is equipped with four dual-core Opteron 8220 CPU, 32 GB of RAM and four built-in NICs. Currently, Sun has a special where you get three X4600 M2s for the price of two. We purchased such a "multipack" to run a large, demanding application related to network security in a virtualised environment. The host OS is Virtual Iron (e.g. a Xen hypervisor) and the guest OSes are RHEL or CentOS respectively. We use two iSCSI SAN disk arrays from EqualLogic to virtualise storage. Unfortunately, our large application does not (yet) run on OpenBSD. However, our firewall cluster is amd64 (pf, pfsync, CARP, pfflowd, etc.) on a pair of relatively "cheap" single dual-core Sun Fire X4100 M2 (will post dmesg later). This cluster also provides a number of infrastructure services, such as for ex. DNS, caching HTTP proxy, reverse proxy (Pound), SSL VPN concentrator (OpenVPN), mail relay, etc. OpenBSD i386-current boots and runs as a guest within Virtual Iron 3.7.4. I intend to post a dmesg as soon as I manage to resolve some weird problem which still prevents me from siphon it to another machine. Regards, Rolf 'top' shows an impressive 8 cores: load averages: 0.19, 0.15, 0.09 19:37:16 20 processes: 19 idle, 1 on processor CPU0 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU1 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU2 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU3 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU4 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU5 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU6 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU7 states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Memory: Real: 10M/57M act/tot Free: 3427M Swap: 0K/1643M used/tot PID USERNAME PRI NICE SIZE RES STATEWAIT TIMECPU COMMAND 28463 root 180 672K 644K idle pause 0:00 0.00% ksh 12385 root 20 3220K 2932K sleep/0 select0:00 0.00% sshd 24344 root 20 844K 1896K sleep/0 poll 0:00 0.00% top 3727 root 20 1144K 1668K sleep/0 select0:00 0.00% sendmail 526 root 20 792K 1376K idle select0:00 0.00% sshd 28736 _syslogd 20 384K 832K sleep/0 poll 0:00 0.00% syslogd 3009 root 20 712K 920K sleep/0 select0:00 0.00% cron 1 root 100 464K 384K idle wait 0:00 0.00% init 27387 root 20 516K 820K idle poll 0:00 0.00% ntpd 19725 root 20 3352K 2932K sleep/5 select0:00 0.00% sshd 23584 _ntp 20 520K 844K idle poll 0:00 0.00% ntpd 7005 root 30 284K 840K idle ttyin 0:00 0.00% getty 4465 root 30 252K 828K idle ttyin 0:00 0.00% getty 32174 root 30 440K 836K idle ttyin 0:00 0.00% getty OpenBSD 4.2 (GENERIC.MP) #1377: Thu Aug 23 10:52:45 MDT 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3757617152 (3583MB) avail mem = 3635957760 (3467MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xfbf20 (83 entries) bios0: vendor American Megatrends Inc. version "080012 " date 04/19/2007 bios0: Sun Microsystems Sun Fire X4600 M2 acpi at mainbus0 not configured ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca4/2 spacing 1 mainbus0: Intel MP Specification (Version 1.4) cpu0 at mainbus0: apid 0 (boot processor) cpu0: Dual-Core AMD Opteron(tm) Processor 8220, 2800.33 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,CX16,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 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Dual-Core AMD Opteron(tm) Processor 8220, 2801.17 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,CX16,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 (ap
Q: Threads Support in ssl(8)?
Hello list, Is there any specific reason, such as for example concerns about security or about stability, why THREADS support is not turned on in OpenBSD's OpenSSL by default? (Apparently, it isn't neither in FreeBSD nor in NetBSD.) Or, was there so far simply no need for THREADS support to be provided by ssl(8)? A project has an urgent need for a compact reverse HTTP/HTTPS proxy. Therefore I updated my earlier port of Pound to its latest stable -2.3.2, which I derived from work done by Pete Vickers et al. http://permalink.gmane.org/gmane.os.openbsd.misc/126141 On sparc64, this port fails to build a secondary OpenSSLin a temporary directory with THREADS support enabled, due to some obscure problem with assembly code and UltraSPARC (I tried both the current stable 0.9.8e and 0.9.7j which is used by 4.2-current). The recommended workaround of configuring OpenSSL with the 'no-asm' option also failed miserably at the 'make test' stage later, although it resolved the compilation/assmbler issue. The solution was to enable THREADS support in OpenSSL of OpenBSD's source tree and to rebuild ssl(8). The resulting Pound port gets much leaner (no hack required with parallel installation of OpenSSL in temporary install directory), builds rapidly and installs cleanly.. So far, Pound-2.3.2 as well as vpnc-0.4.0 and OpenVPN-2.0.9 run fine on both i386 and sparc64 of 4.2-current using ssl(8) with THREADS enabled. I am aware that the project is currently in release lock. Once unlocked, is there any chance that enabling THREADS support per default would gain some traction? This would facilitate the building of a clean port for Pound considerably. If there is any interest, I can make available my updated Pound-2.3.2 port available. Thanks, Rolf
Slides of Talk about OpenBGPD at DE-CIX
Bernhard Krvnung of DE-CIX recently gave a talk about OpenBGPd at SwiNOG 14: http://www.swinog.ch/meetings/swinog14/070530-openbgpd-swinog-bk-en.pdf A comitter might want to add it to the collections in events.html and/or in papers/index.html . Thanks, Rolf
Re: ath(4) testers needed: AR2413, AR5413, AR5424 and AR5212 11a mode
My new miniPCI with AR2413 in 11b mode is recognized under -current on a WRAP, but it fails to associate and sometimes locks up the entire system, as implictly warned by Reyk in his commit for src/sys/dev/ic/ath.con 19 Sept 2006. This ath(4) device is a wlm54g23 Compex WLM54G 200mW Atheros 802.11b/g miniPCI wireless card from PCEngines. Please find some debug output below, as suggested by Reyk. I am happy to provide more information, and to test patches against -current, in the hope to assist getting these newer ath chip sets to transmit also in 11b mode. Thanks, Rolf [EMAIL PROTECTED] root]# ifconfig ath0 up [EMAIL PROTECTED] root]# ifconfig ath0 ath0: flags=8863 mtu 1500 lladdr 00:80:48:7e:b4:e5 groups: wlan media: IEEE802.11 autoselect (DS1 mode 11b) status: no network ieee80211: nwid FON_crosscom chan 3 bssid 00:18:84:10:62:1d 92% inet6 fe80::280:48ff:fe7e:b4e5%ath0 prefixlen 64 scopeid 0x1 [EMAIL PROTECTED] root]# ifconfig ath0 ath0: flags=8863 mtu 1500 lladdr 00:80:48:7e:b4:e5 groups: wlan media: IEEE802.11 autoselect (DS1) status: no network ieee80211: nwid "" inet6 fe80::280:48ff:fe7e:b4e5%ath0 prefixlen 64 scopeid 0x1 [EMAIL PROTECTED] root]# [EMAIL PROTECTED] root]# ifconfig -M ath0 ath0: flags=8863 mtu 1500 lladdr 00:80:48:7e:b4:e5 groups: wlan media: IEEE802.11 autoselect (DS1) status: no network ieee80211: nwid "" nwid FON_crosscom chan 3 bssid 00:18:84:10:62:1d 87% 54M short_preamble,short_slottime inet6 fe80::280:48ff:fe7e:b4e5%ath0 prefixlen 64 scopeid 0x1 [EMAIL PROTECTED] root]# ifconfig -M ath0 [EMAIL PROTECTED] root]# dmesg OpenBSD 4.1-current (WRAP12) #0: Sun Jun 3 11:15:57 CEST 2007 [EMAIL PROTECTED]:/home/rs/downloads/OpenBSD/flashboot/flashboot/obj/WRAP12 RTC BIOS diagnostic error 80 cpu0: Geode(TM) Integrated Processor by National Semi ("Geode by NSC" 586-class) 267 MHz cpu0: FPU,TSC,MSR,CX8,CMOV,MMX cpu0: TSC disabled real mem = 133791744 (127MB) avail mem = 109572096 (104MB) RTC BIOS diagnostic error 80 mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/08/05, BIOS32 rev. 0 @ 0xfc622 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xe/0x8000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "Cyrix GXm PCI" rev 0x00 ath0 at pci0 dev 13 function 0 "Atheros AR2413" rev 0x01: irq 12 ath0: AR2413 7.8 phy 4.5 rf 5.6, FCC2A*, address 00:80:48:7e:b4:e5 sis0 at pci0 dev 14 function 0 "NS DP83815 10/100" rev 0x00, DP83816A: irq 10, address 00:0d:b9:01:a0:a0 nsphyter0 at sis0 phy 0: DP83815 10/100 PHY, rev. 1 sis1 at pci0 dev 15 function 0 "NS DP83815 10/100" rev 0x00, DP83816A: irq 9, address 00:0d:b9:01:a0:a1 nsphyter1 at sis1 phy 0: DP83815 10/100 PHY, rev. 1 sis2 at pci0 dev 16 function 0 "NS DP83815 10/100" rev 0x00, DP83816A: irq 11, address 00:0d:b9:01:a0:a2 nsphyter2 at sis2 phy 0: DP83815 10/100 PHY, rev. 1 gscpcib0 at pci0 dev 18 function 0 "NS SC1100 ISA" rev 0x00 gpio0 at gscpcib0: 64 pins "NS SC1100 SMI" rev 0x00 at pci0 dev 18 function 1 not configured pciide0 at pci0 dev 18 function 2 "NS SCx200 IDE" rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 1-sector PIO, LBA, 125MB, 256512 sectors wd0(pciide0:0:0): using PIO mode 4 "NS SCx200 AUDIO" rev 0x00 at pci0 dev 18 function 3 not configured geodesc0 at pci0 dev 18 function 5 "NS SC1100 X-Bus" rev 0x00: iid 6 revision 3 wdstatus 0 isa0 at gscpcib0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 midi0 at pcppi0: gscsio0 at isa0 port 0x2e/2: SC1100 SIO rev 1: ACB1 ACB2 iic0 at gscsio0 iic1 at gscsio0 lmtemp0 at iic1 addr 0x48: lm77 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pccom0: console biomask e1ef netmask ffef ttymask ffef rd0: fixed, 30720 blocks dkcsum: wd0 matches BIOS drive 0x80 root on rd0a swap on rd0b dump on rd0b clock: unknown CMOS layout WARNING: clock time much less than file system time WARNING: using file system time WARNING: CHECK AND RESET THE DATE! [EMAIL PROTECTED] root]# Filtered output to avoid dumping other WLAN traffic than the two MACs of interest. ':b4:e5' is my ath0, ':62:1d' is my public FONera access point, see output of 'ifconfig -M ath0' above: [EMAIL PROTECTED] root]# tcpdump -y ieee802_11_radio -eni ath0 | grep -e ':b4:e5' -e ':62:1d' tcpdump: listening on ath0, link-type IEEE802_11_RADIO 10:02:43.791541 0:18:84:10:62:1d > ff:ff:ff:ff:ff:ff, bssid 0:18:84:10:62:1d: 802.11: beacon[|802.11]
"OpenBSD-style" Templates for MagicPoint Presentations
Hello list, so far I have been unsuccessful in locating templates (and fonts?) for MagicPoint presentations in "OpenBSD-style", such as used in for example: http://openbsd.org/papers/ven05-henning/index.html http://openbsd.org/papers/opencon06-network/index.html http://openbsd.org/papers/opencon06-drivers/index.html http://openbsd.org/papers/linuxtag06-network/index.html Can someone point me to those templates and fonts, and/or provide source of sample slides, provided that they are "open"? I am thinking about ging a talk about OpenBSD (with some applied examples) targeted to fellow ICT staff of international humanitarian organisations who provide IT and Communication services to emergency and relief operations. There, I believe, OpenBSD has great potential, as it provides a robust and cost-efficient platform (also on legacy hardware) that can cover several pressing needs, such as dynamic routing, redundant firewals, VPN over public networks such as wireless links (Wireless LAN, satellite, Internet, etc.), network & system monitoring and SLA verification, spam filtering to protect low-capacity links from transporting expensive rubbish, etc. Currently, this field is still largely dominated by commercial software and solution providers. However, as Open Source Software is gaining more and more attention among governmental organisations, those governments as major donors of international aid agencies will sooner or later start to ask questions why aid agencies spend the donors' money on software and licenses. It would be nice to prepare and to give the talk with MagicPoint slides in "OpenBSD-style" using my old Dell Inspiron 4000 laptop that happily runs i386-current :-) Thanks for your help, Rolf
Re: msk(4) with SK-9S91: Can not set 1000baseSX Single Mode Fiber Media Type
Hi Mark On 2/3/07, Mark Kettenis <[EMAIL PROTECTED]> wrote: Regarding the high interrupt load on the v210; try disconnecting the CD-ROM/DVD-ROM. Removing the CD drives silenced the interrupts, and the CPU load dropped to 0%, thanks. Can you try the attached diff? It has some debug printf's in there, so please send me a dmesg. After CVSupdating last night and applying your patch, the fiber NICs worked for a few pings, but since they changed their status from "active" to "no carrier". Please find some debug output below. By the way, the large Marvell chip on the SK-9S91 NIC is labelled "88E8021". Thanks, Rolf # ifconfig lo0: flags=8049 mtu 33192 groups: lo inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8 bge0: flags=8843 mtu 1500 lladdr 00:14:4f:64:0c:52 groups: egress media: Ethernet autoselect (100baseTX full-duplex) status: active inet 10.7.91.218 netmask 0xff80 broadcast 10.7.91.255 inet6 fe80::214:4fff:fe64:c52%bge0 prefixlen 64 scopeid 0x1 bge1: flags=8802 mtu 1500 lladdr 00:14:4f:64:0c:53 media: Ethernet autoselect (1000baseT full-duplex) status: active bge2: flags=8802 mtu 1500 lladdr 00:14:4f:64:0c:54 media: Ethernet autoselect (none) status: no carrier bge3: flags=8802 mtu 1500 lladdr 00:14:4f:64:0c:55 media: Ethernet autoselect (none) status: no carrier msk0: flags=8843 mtu 1500 lladdr 00:00:5a:72:fc:59 media: Ethernet autoselect (none) status: no carrier inet6 fe80::200:5aff:fe72:fc59%msk0 prefixlen 64 scopeid 0x5 inet 10.20.0.218 netmask 0xff00 broadcast 10.20.0.255 pflog0: flags=0<> mtu 33192 enc0: flags=0<> mtu 1536 # # ifconfig -m msk0 msk0: flags=8843 mtu 1500 lladdr 00:00:5a:72:fc:59 media: Ethernet autoselect (none) status: no carrier supported media: media none media 1000baseSX media 1000baseSX mediaopt full-duplex media autoselect inet6 fe80::200:5aff:fe72:fc59%msk0 prefixlen 64 scopeid 0x5 inet 10.20.0.218 netmask 0xff00 broadcast 10.20.0.255 # # dmesg console is /[EMAIL PROTECTED],60/[EMAIL PROTECTED]/[EMAIL PROTECTED],3f8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2007 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 4.0-current (GENERIC) #0: Mon Feb 5 02:19:55 CET 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/compile/GENERIC total memory = 1073741824 avail memory = 969416704 using 6553 buffers containing 53682176 bytes of memory bootpath: /[EMAIL PROTECTED],60/[EMAIL PROTECTED],0/[EMAIL PROTECTED],0 mainbus0 (root): Sun Fire V210 cpu0 at mainbus0: SUNW,UltraSPARC-IIIi (rev 3.4) @ 1336 MHz, version 0 FPU cpu0: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K external (64 b/l) memory-controller at mainbus0 not configured schizo0 at mainbus0: "Tomatillo", version 4, ign 7c0, bus B 0 to 0 schizo0: dvma map c000-dfff, iotdb 4d16000-4d96000 pci0 at schizo0 bge0 at pci0 dev 2 function 0 "Broadcom BCM5704C" rev 0x00, BCM5704 B0 (0x2100): ivec 0x7c8, address 00:14:4f:64:0c:52 brgphy0 at bge0 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 bge1 at pci0 dev 2 function 1 "Broadcom BCM5704C" rev 0x00, BCM5704 B0 (0x2100): ivec 0x7c9, address 00:14:4f:64:0c:53 brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 schizo1 at mainbus0: "Tomatillo", version 4, ign 780, bus A 0 to 0 schizo1: dvma map c000-dfff, iotdb 547e000-54fe000 pci1 at schizo1 ebus0 at pci1 dev 7 function 0 "Acer Labs M1533 ISA" rev 0x00 "flashprom" at ebus0 addr 0-f, 290-290 not configured rtc0 at ebus0 addr 70-71: m5819p pcfiic0 at ebus0 addr 320-321 ipl 46 iic0 at pcfiic0 "SUNW,i2c-imax" at iic0 addr 0xb not configured "SUNW,i2c-imax" at iic0 addr 0xc not configured "at24c64" at iic0 addr 0x51 not configured "at24c64" at iic0 addr 0x54 not configured "at24c64" at iic0 addr 0x58 not configured "at34c02" at iic0 addr 0x5b not configured "at34c02" at iic0 addr 0x5c not configured "at34c02" at iic0 addr 0x5d not configured "at34c02" at iic0 addr 0x5e not configured "ds1307" at iic0 addr 0x68 not configured "at24c64" at iic0 addr 0x28 not configured "pca9555" at iic0 addr 0x22 not configured "pca9555" at iic0 addr 0x23 not configured "pca9555" at iic0 addr 0x34 not configured "pca9556" at iic0 addr 0x38 not configured power0 at ebus0 addr 800-82f ipl 32: can't map register space com0 at ebus0 addr 3f8-3ff ipl 44: ns16550a, 16 byte fifo com0: console com1 at ebus0 addr 2e
Re: High Interrupt Load cased by pciide with sparc64 on SUN V210
The high interrupt load vanished after removing the CD-ROM drives from both V210, as suggested by Mark Kettenis. Now the CPU load is down to 0%, as one expects, and the systems are much more performant and responsive than before :-) # iostat -w 1 ttycd0 sd0 cpu tin tout KB/t t/s MB/s KB/t t/s MB/s us ni sy in id 0 21 0.00 0 0.00 8.18 2 0.01 3 0 0 36 61 0 172 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 0 57 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 0 57 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 0 57 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 0 57 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 0 57 0.00 0 0.00 16.00 2 0.03 0 0 0 0100 0 57 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 ^C # Thanks to Mark for his suggestion, Rolf
Re: msk(4) with SK-9S91: Can not set 1000baseSX Single Mode Fiber Media Type
Both boxes and fiber NICs work fine under Solaris 9 using Syskonnect's proprietary skge driver and a short cross-over fiber patch. So it is definitely not an issue with with the hardware setup, but with OpenBSD. I'll have the fiber NICs for another 10 days before I'll deploy them in a customer's setup. Until then, I would be happy to apply any diffs and retest. Thanks, Rolf
Re: vpn bridge misbehavior
Hi, On 2/2/07, Jonathan Whiteman <[EMAIL PROTECTED]> wrote: I'd like to get into a detailed explanation of the network topology I'm working with here but I don't want to scare off anyone by opening with a 3 page email. Your subject implies that you built a layer-2 LAN-to-LAN bridge over an (IPSec or OpenVPN?) VPN tunnel. Not beening a OpenBSD nor VPN specialist yet, still I would love to see your detailed three page description, as I am currently experimenting with a similar setup (and got a prototype to work last night in the lab). Rolf
Re: High Interrupt Load cased by pciide with sparc64 on SUN V210
On 2/1/07, Stuart Henderson <[EMAIL PROTECTED]> wrote: I suspect this is an interrupt routing problem for the pci slot, I don't know about V210 but Netra T1 105 pci slot only started working a bit before 4.0 came out. See if it clears up after pulling the PCI card...(I know, if you're putting SMF nics in it's unlikely to be a solution for you, but it will at least give another data point). I've pulled out the fiber NICs out of both boxes, but the high interrupt load persists. I can do the proof of concept without the fiber connection, using the built-in copper Gig interfaces instead. However, if the CPU is still permanently loaded by those interrupts, then it is not so nice to produce performance measurement (well, they are fairly pessimistic). I look forward to seize the opportunity and deposit this concern in connection with missing documentation with a SUN representative. Still, I am happy to test any patches which might mitigate the problem. Thanks, Rolf
High Interrupt Load cased by pciide with sparc64 on SUN V210
Hello misc, After having installed 4.0-current on two identically configured SUN V210 (see dmesg below), I found that their performance was unusually bad, notably with disk I/O. top reveals a permanent interrupt load of between 30 to over 50% !? # top load averages: 0.09, 0.17, 0.08 19:52:16 13 processes: 12 idle, 1 on processor CPU states: 1.9% user, 0.0% nice, 1.6% system, 39.0% interrupt, 57.5% idle Memory: Real: 11M/122M act/tot Free: 880M Swap: 0K/487M used/tot PID USERNAME PRI NICE SIZE RES STATEWAIT TIMECPU COMMAND 1643 root 20 832K 2360K idle select 0:02 0.00% sshd 30242 root 20 3544K 3504K sleepselect 0:01 0.00% sshd 24667 root 20 480K 1072K idle select 0:00 0.00% inetd 2435 root 20 1592K 2136K sleepselect 0:00 0.00% sendmail 20073 root 180 824K 616K sleeppause0:00 0.00% ksh 24745 root 20 536K 1056K idle poll 0:00 0.00% ntpd 29783 root 20 664K 1184K sleepselect 0:00 0.00% cron 25532 root 30 352K 1104K idle ttyin0:00 0.00% getty 21605 _syslogd 20 544K 1000K idle poll 0:00 0.00% syslogd 1 root 100 536K 424K idle wait 0:00 0.00% init 24060 root 20 520K 976K idle netio0:00 0.00% syslogd 3809 _ntp 20 408K 1056K idle poll 0:00 0.00% ntpd 24849 root 310 504K 1648K onproc -0:00 0.00% top vmstat hints that pciide0 generates interrupts with a very high rate, although there is hardly anything running on the boxes: # vmstat -i interrupt total rate bge0 5143 com0 820 pciide0 134564203 879504 siop02158 14 siop1 10 clock 15327 100 Total 134582285 879622 # uptime 7:50PM up 3 mins, 1 user, load averages: 0.27, 0.21, 0.09 # # iostat -w 1 ttycd0 sd0 cpu tin tout KB/t t/s MB/s KB/t t/s MB/s us ni sy in id 0 29 0.00 0 0.00 15.09 1 0.01 0 0 0 36 64 0 171 0.00 0 0.00 0.00 0 0.00 0 0 0 38 62 0 57 0.00 0 0.00 0.00 0 0.00 0 0 0 33 67 0 57 0.00 0 0.00 0.00 0 0.00 0 0 0 38 62 0 57 0.00 0 0.00 0.00 0 0.00 0 0 0 28 72 0 57 0.00 0 0.00 0.00 0 0.00 0 0 0 34 66 0 57 0.00 0 0.00 0.00 0 0.00 0 0 0 27 73 0 57 0.00 0 0.00 0.00 0 0.00 0 0 0 40 60 0 57 0.00 0 0.00 0.00 0 0.00 0 0 0 31 69 0 57 0.00 0 0.00 0.00 0 0.00 0 0 0 36 64 0 57 0.00 0 0.00 0.00 0 0.00 0 0 0 29 71 0 57 0.00 0 0.00 0.00 0 0.00 0 0 0 31 69 0 57 0.00 0 0.00 0.00 0 0.00 0 0 0 34 66 0 57 0.00 0 0.00 0.00 0 0.00 0 0 0 37 63 0 57 0.00 0 0.00 0.00 0 0.00 0 0 0 32 68 Maybe I shoud mention that I was lazy and installed everything under / into a single partition because it's only a lab setup. Also, in both boxes, I installed a SK-9S91 PCI 1 Gbit/s fiber NIC, in addition to the four on-board bge NICs. Rebooting multiple times of both boxes did not cure the high interrupt rate, and enabling softupdates on /dev/sd0a did not help either. The third-lat line in the output of dmesg below is somewhat intrigueing: "No counter-timer -- using %tick at 1336MHz as system clock. root on sd0a" But according to other dmesg from the archives, this seems to be common among sparc64 installs. In the archives, I found postings regarding a similar problem on an Ultra 5. Apparently, the only recommendation there was to enable softupdates. I remember having observed similar performance problems on my own Ultra 5 some months ago under OpenBSD 3.9, which I was unable to resolve. Shall I try a re-install with more partitions, respectively to add more partitions for the usual mount points? Anything to do from with OpenBoot in order to avoid interrupt conflicts between pciide0 and the SK-9S91 PCI NIC, for example? Is there anything else that I should try in order to silence that interrupt source? I am happy to rebuild the kernel after patching and to re-test. Thanks for your attention and any suggestions, Rolf # disklabel sd0 # /dev/rsd0c: type: SCSI disk: SCSI disk label: SUN72G cyl 14087 flags: bytes/sector: 512 sectors/track: 424 tracks/cylinder: 24 sectors/cylinder: 10176 cylinders: 14087 total sectors: 143349312 rpm: 10025 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 16 partitions: # sizeoffset fstype [fsize bsize cpg] a: 7704 0 4.2BSD 2048 16384 16 # Cyl 0 - 6878 b:997248 7704swap # Cyl
Re: msk(4) with SK-9S91: Can not set 1000baseSX Single Mode Fiber Media Type
Hi Mark Most likely something is not quite right with the eephy(4) driver. eephy_status() in sys/dev/mii/eephy.c seems to be a candidate for closer examination. It appears to fall through the if() clause and does the else part, although we have a NIC with MIIF_IS_1000X : 319:if (sc->mii_flags & MIIF_IS_1000X) { 320:if (ssr & E1000_SSR_1000MBS) 321: mii->mii_media_active |= IFM_1000_SX; 322:} else { 323:if (ssr & E1000_SSR_1000MBS) 324: mii->mii_media_active |= IFM_1000_T; 325:else if (ssr & E1000_SSR_100MBS) 326: mii->mii_media_active |= IFM_100_TX; 327:else 328: mii->mii_media_active |= IFM_10_T; 329:} Could you test some diffs for me on that machine? Yes, I am happy to do that - I hope that I can continue to use those two machines over the next few days. Just preparing them with CVSupped source tree. Rolf
Re: msk(4) with SK-9S91: Can not set 1000baseSX Single Mode Fiber Media Type
On 1/30/07, Siegbert Marschall <[EMAIL PROTECTED]> wrote: try media 1000baseT mediaopt full-duplex , 1G fiberlinks should be always fullduplex, rest ist not relevant since it's purely a hardware- question. wonder how the thing got it's head on 100BaseTX... apart from that it's a good idea to test them with something else, to make sure the fibers are crossed and signal-levels are okay. with single-mode fiber and short cables sometimes you need to insert a dampening-block since the signal can be too strong for the receiver, don't think it's the case here though. Thanks for your quick reply. Unfortunately, this does not activate the link either: # ifconfig msk0 media 1000baseT mediaopt full-duplex # ifconfig -m msk0 msk0: flags=8843 mtu 1500 lladdr 00:00:5a:72:fc:58 media: Ethernet 1000baseT full-duplex (none) status: no carrier supported media: media none media 10baseT media 10baseT mediaopt full-duplex media 100baseTX media 100baseTX mediaopt full-duplex media 1000baseT media 1000baseT mediaopt full-duplex media autoselect inet6 fe80::200:5aff:fe72:fc58%msk0 prefixlen 64 scopeid 0x5 inet 10.10.0.218 netmask 0xff00 broadcast 10.10.0.255 # Three months ago I used the exact same fiber patch cable with two other SK-9S91 under Solaris 8 in some other V210 or V240, and the fiber link worked fine back then. Thus, the fiber should be OK (crossover, attenuation, etc.). But will cross-check that by installing Solaris again. Further, I noticed ifmedia(4) differentiates between 1000baseT, SX and LX. From this I actually realize that I should be able to set 1000baseLX for single mode fiber, not SX which is for multi mode fiber. Or, are you saying that the Marvell PHY 88112 does not really care about if T, SX or LX is set, because for the optical "GBIC" electrically all is the same? Rolf
msk(4) with SK-9S91: Can not set 1000baseSX Single Mode Fiber Media Type
Hello misc, Two identically configured SUN V210, each equipped with a SK-9S91 PCI NIC (single port, single mode fiber 1 Gbit/s), run -current snapshot dated 20 Jan 07 The kernel detects those fiber NICs, besides the four on-board bge, see dmesg below. After boot, the msk0 come up in autoselect media type, but the two fiber NICs' link status remains at "no carrier", despite having connected the two NIC with a cross-over fiber patch cable and forcing them "up". Forcing the media type "1000baseSX" according to msk(4) fails: # ifconfig msk0 media 1000baseSX ifconfig: SIOCSIFMEDIA: Invalid argument # Indeed, this option is missing in the list of media types and options supported by the card: # ifconfig -m msk0 msk0: flags=8843 mtu 1500 lladdr 00:00:5a:72:fc:58 media: Ethernet autoselect (100baseTX half-duplex) status: no carrier supported media: media none media 10baseT media 10baseT mediaopt full-duplex media 100baseTX media 100baseTX mediaopt full-duplex media 1000baseT media 1000baseT mediaopt full-duplex media autoselect inet6 fe80::200:5aff:fe72:fc58%msk0 prefixlen 64 scopeid 0x5 inet 10.10.0.218 netmask 0xff00 broadcast 10.10.0.255 # Maybe I am mistaken by assuming that "1000baseSX" should be accepted by msk() for these NICs? After taking a look at the msk() and eephy() driver sources, I still can not figure out if I have a misconception about the use of msk(), or the fiber NICs features, or even if there is a problem with the driver(s) and Gig fiber support. Both fiber NICs are new out-of-the-box. To exclue any hardware problem, I might test them under Solaris 8, According to prior experience, I know that they should work after installing a suitable driver. I can patch and re-test, if this should be of interest. Thanks for any hints and suggestions, Rolf # dmesg console is /[EMAIL PROTECTED],60/[EMAIL PROTECTED]/[EMAIL PROTECTED],3f8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2007 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 4.0-current (GENERIC) #1049: Fri Jan 19 18:36:23 MST 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/sparc64/compile/GENERIC total memory = 1073741824 avail memory = 969416704 using 6553 buffers containing 53682176 bytes of memory bootpath: /[EMAIL PROTECTED],60/[EMAIL PROTECTED],0/[EMAIL PROTECTED],0 mainbus0 (root): Sun Fire V210 cpu0 at mainbus0: SUNW,UltraSPARC-IIIi (rev 3.4) @ 1336 MHz, version 0 FPU cpu0: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K external (64 b/l) memory-controller at mainbus0 not configured schizo0 at mainbus0: "Tomatillo", version 4, ign 7c0, bus B 0 to 0 schizo0: dvma map c000-dfff, iotdb 4d16000-4d96000 pci0 at schizo0 bge0 at pci0 dev 2 function 0 "Broadcom BCM5704C" rev 0x00, BCM5704 B0 (0x2100): ivec 0x7c8, address 00:14:4f:64:0c:52 brgphy0 at bge0 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 bge1 at pci0 dev 2 function 1 "Broadcom BCM5704C" rev 0x00, BCM5704 B0 (0x2100): ivec 0x7c9, address 00:14:4f:64:0c:53 brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0 schizo1 at mainbus0: "Tomatillo", version 4, ign 780, bus A 0 to 0 schizo1: dvma map c000-dfff, iotdb 547e000-54fe000 pci1 at schizo1 ebus0 at pci1 dev 7 function 0 "Acer Labs M1533 ISA" rev 0x00 "flashprom" at ebus0 addr 0-f, 290-290 not configured rtc0 at ebus0 addr 70-71: m5819p pcfiic0 at ebus0 addr 320-321 ipl 46 iic0 at pcfiic0 "SUNW,i2c-imax" at iic0 addr 0xb not configured "SUNW,i2c-imax" at iic0 addr 0xc not configured "at24c64" at iic0 addr 0x51 not configured "at24c64" at iic0 addr 0x54 not configured "at24c64" at iic0 addr 0x58 not configured "at34c02" at iic0 addr 0x5b not configured "at34c02" at iic0 addr 0x5c not configured "at34c02" at iic0 addr 0x5d not configured "at34c02" at iic0 addr 0x5e not configured "ds1307" at iic0 addr 0x68 not configured "at24c64" at iic0 addr 0x28 not configured "pca9555" at iic0 addr 0x22 not configured "pca9555" at iic0 addr 0x23 not configured "pca9555" at iic0 addr 0x34 not configured "pca9556" at iic0 addr 0x38 not configured power0 at ebus0 addr 800-82f ipl 32: can't map register space com0 at ebus0 addr 3f8-3ff ipl 44: ns16550a, 16 byte fifo com0: console com1 at ebus0 addr 2e8-2ef ipl 44: ns16550a, 16 byte fifo "rmc-comm" at ebus0 addr 3e8-3ef ipl 44 not configured "Acer Labs M7101 Power" rev 0x00 at pci1 dev 6 function 0 not configured ohci0 at pci1 dev 10 function 0 "Acer Labs M5237 USB" rev 0x03: ivec 0x7a7, version 1.0, legacy
Re: No Watchdog with Current snapshot/i386/ on Nokia IP120
On 9/17/06, Stuart Henderson <[EMAIL PROTECTED]> wrote: Reboot may be easier. Looking at /usr/src/sys/arch/i386/i386/machdep.c, there's a Geode-specific reset operation used, but there's a chance it is an SC1100-only function that won't work on a plain Geode system. If that's the case, and seeing as you appear to have a standard PC keyboard controller (which is used to reset normal systems but is absent from some Geode boards, notably WRAP, hence the alternative function), you can try editing this file and commenting-out "cpuresetfn = natsem6x86_cpureset;" from natsem6x86_cpu_setup() and rebuilding the kernel; this way it will use the normal PC methods instead. If this does the trick, the outl/outb are probably hanging your system, in which case the natsem6x86_cpu_setup needs to do additional CPU detection and only use the alternative reset function on SC1100 systems. As pointed out earlier, this does the trick. Now, I try to contribute a proper patch which discriminates between Geode CPUs in Nokia and WRAP & Soekris boards in order to call an appropriate reset function. Using debug kernels customized with 'option CPUDEBUG' does not show an obvious difference within the '/src/sys/arch/i386/i386/machdep.c' module between a Nokia (booting from hard disk) and a WRAP (network booting using PXEboot), see dmesg below. Would it be acceptable to somehow use the 'bios0' string within machdep.c to setup 'cpuresetfn' at boot time, or within 'cpu_reset()' later "at run time" in order to discriminate Nokia motherboards from WRAPs and Soekris' ? Or, do I overlook some parameter that would allow to discriminate those motherboards within machdep.c? Or finally, more radical, should the setting of the global variable 'cpuresetfn' be postponed to where the motherboard / BIOS is detected, and not prematurely in the CPU detection stage in machdep.c? Thanks in advance for your guidance, Rolf dmesg from Nokia IP120, 'GENERIC' kernel built with 'option CPUDEBUG': OpenBSD 4.0-current (GENERIC) #14: Fri Oct 6 13:34:12 CEST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: family 5 model 4 step 0 cpu0: cpuid level 2 cache eax 7001 ebx 0 ecx 0 edx 80 cpu0: Geode(TM) Integrated Processor by National Semi ("Geode by NSC" 586-class) 267 MHz cpu0: FPU,TSC,MSR,CX8,CMOV,MMX cpu0: TSC disabled real mem = 133787648 (130652K) avail mem = 114634752 (111948K) using 1658 buffers containing 6791168 bytes (6632K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(05) BIOS, date 07/17/00, BIOS32 rev. 0 @ 0xeb0a0, SMBIOS rev. 2.3 @ 0xe d2a8 (32 entries) bios0: Jabil/Nokia IP110 pcibios0 at bios0: rev 2.1 @ 0xe8000/0x669 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf4fb0/80 (3 entries) pcibios0: no compatible PCI ICU found: ICU vendor 0x1078 product 0x0100 pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xe8000/0x4000! 0xec000/0x4000! cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "Cyrix GXm PCI" rev 0x00 fxp0 at pci0 dev 14 function 0 "Intel 82559ER" rev 0x09, i82559S: irq 11, address 00:a0:8e:21:88:98 ... dmesg from WRAP1C, PXE-booting over network 'RAMDISK_CD' kernel built with 'option CPUDEBUG': PC Engines WRAP.1C/1D/1E v1.11 640 KB Base Memory 130048 KB Extended Memory 01F0 - no drive found ! ROM segment 0xe000 length 0x8000 reloc 0x Etherboot 5.4.1 (GPL) http://etherboot.org Drivers: NATSEMI Images: NBI ELF PXE Exports: PXE Protocols: DHCP TFTP NFS TFTM HTTP DNS Relocating _text from: [00088f80,0009fd60) to [07ee9220,07f0) Boot from (N)etwork or (Q)uit? Probing pci nic... [dp83815] natsemi_probe: MAC addr 00:0D:B9:01:A0:A0 at ioaddr 0X1000 natsemi_probe: Vendor:0X100B Device:0X0020 dp83815: Transceiver default autoneg. enabled, advertise 100 full duplex. dp83815: Transceiver status 7869 advertising 05E1 dp83815: Setting half-duplex based on negotiated link capability. Searching for server (DHCP)...\ Me: 10.0.0.21, DHCP: 10.0.0.3, TFTP: 10.0.0.3, Gateway 10.0.0.1, Nameserver 10.0.0.1 Loading 10.0.0.3:pxeboot (0049K done probing: pc0 com0 pci pxe![2.1] mem[640K 125M a20=on] disk: net: mac 00:0d:b9:01:a0:a0, ip 10.0.0.21, server 10.0.0.3 OpenBSD/i386 PXEBOOT 1.07 switching console to com0 OpenBSD/i386 PXEBOOT 1.07 com0: changing speed to 38400 baud in 5 seconds, change your terminal to match! com0: 38400 baud booting tftp:/bsdCPUDEBUG.rd: 5034740+740164 [52+164384+150221]=0x5cecd0 dp83815: Setting half-duplex based on negotiated link capability. entry point at 0x200120 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2006 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 4.0-current (RAMDISK_CD) #0: Fri Oct 6 13:54:24 CEST 2006 [EMAIL
Re: No Watchdog with Current snapshot/i386/ on Nokia IP120
Stuart thanks for your rapid followup. Indeed, your hint about modifying the reset function fixed the 'reboot' funtion (see below) - great! Implicitely this also confirms that the CPU on the Nokia plattform is very likely not an SC1100/1200 but some other (earlier) Geode processor. On 9/17/06, Stuart Henderson <[EMAIL PROTECTED]> wrote: Some other Geode-based systems use separate components for these. The watchdog is presumably in the parts of the SC1100 other than the CPU. If your board has a watchdog at all, it's not likely to emulate the SC1100 watchdog. Unfortunately, cooling fins are glued on top of the BGA-housing of the processor in the Nokia plattform. Therefore, unlike with WRAP plattforms, the chip designation of the Geode remains hidden. Some reports hint that it could be the GX1, which was a predecessor of the SC1100 family. While the latter has an on-chip hardware watchdog according to its manual, the predecessor is apparently not. However, it is likely that the Geode I/O co-processor CS5530A includes a programmable watchdog timer - I will check that if I can get access to the datasheet (downloading datasheets from AMD is no so straightforward anymore as it used to be...). A quick survey of all other chips showed that there is no watchdog (LM2636M, CY2292SL, HIN211, Flash with BIOS-E from Insyde Software). Reboot may be easier. Looking at /usr/src/sys/arch/i386/i386/machdep.c, there's a Geode-specific reset operation used, ... ... you can try editing this file and commenting-out "cpuresetfn = natsem6x86_cpureset;" from natsem6x86_cpu_setup() and rebuilding the kernel; this way it will use the normal PC methods instead. If this does the trick, the outl/outb are probably hanging your system, in which case the natsem6x86_cpu_setup needs to do additional CPU detection and only use the alternative reset function on SC1100 systems. As recommended, I comment out the two 'outb' statements in the Geode-specific reset function and built a fresh kernel which now reboots flawlessly :-) Now, I will try to figure out and contribute a clean patch that discriminates the Nokia from other Geode plattform like WRAP and Soekris. I am glad my two Nokia IP120 will get a second, long life as Internet firewall & routing gateway cluster under OpenBSD :-) Thanks, Rolf
No Watchdog with Current snapshot/i386/ on Nokia IP120
Hello, The current snapshot/i386 installed and runs successfully on a Nokia IP120 appliance with a 10 GB harddisk where I have overwritten its original IPSO/Checkpoint firewall image, see dmesg below. However, I find that no watchdog is available, as geodesc (Geode SC1100/SCx200 IAOC driver) does not get loaded, although it is in the default GENERIC kernel config. While comparing with dmesg of WRAP plattforms, I notice that on Nokia lines such as the following are missing: ... gscpcib0 at pci0 dev 18 function 0 "NS SC1100 ISA" rev 0x00 ... geodesc0 at pci0 dev 18 function 5 "NS SC1100 X-Bus" rev 0x00: iid 6 revision 3 wdstatus 0 ... Does gscpcib* not get loaded on Nokia because there is a Cyrix device sitting on the PCI bus? Consequently, does geodesc* not get loaded because gscpcib* is absent? One motivation for me trying to use 'sysctl kern.watchdog.auto=1', 'sysctl kern.watchdog.period=30', and start 'watchdogd' is the problem that 'reboot' on the Nokia plattform hangs indefinitely after OpenBSD shuts down and successfully synced disks. This problem has been reported earlier by others, and I just attempted to create a workaround using Geode's hardware watchdog. Can anyone please provide me guidance how I could debug the watchdog (and eventually the reboot) problems further? I have some experience in building custom kernels, if that should be necessary. But I do not yet know enough about PCI devices and drivers in order to interpret the dmesg output correctly. Thanks, Rolf # # sysctl kern.watchdog.auto sysctl: kern.watchdog.auto: value is not available # sysctl kern.watchdog.period sysctl: kern.watchdog.period: value is not available # # sysctl -a | grep watchdog # (<-- no output, e.g. there is no watchdog stuff) # # watchdogd watchdogd: no watchdog timer available # # # dmesg OpenBSD 4.0 (GENERIC) #1104: Fri Sep 1 11:54:27 MDT 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by National Semi ("Geode by NSC" 586-class) 267 MHz cpu0: FPU,TSC,MSR,CX8,CMOV,MMX cpu0: TSC disabled real mem = 133787648 (130652K) avail mem = 114688000 (112000K) using 1658 buffers containing 6791168 bytes (6632K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(05) BIOS, date 07/17/00, BIOS32 rev. 0 @ 0xeb0a0, SMBIOS rev. 2.3 @ 0xed2a8 (32 entries) bios0: Jabil/Nokia IP110 pcibios0 at bios0: rev 2.1 @ 0xe8000/0x669 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf4fb0/80 (3 entries) pcibios0: no compatible PCI ICU found: ICU vendor 0x1078 product 0x0100 pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xe8000/0x4000! 0xec000/0x4000! cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "Cyrix GXm PCI" rev 0x00 fxp0 at pci0 dev 14 function 0 "Intel 82559ER" rev 0x09, i82559S: irq 11, address 00:a0:8e:21:88:98 inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4 fxp1 at pci0 dev 15 function 0 "Intel 82559ER" rev 0x09, i82559S: irq 10, address 00:a0:8e:21:88:99 inphy1 at fxp1 phy 1: i82555 10/100 PHY, rev. 4 fxp2 at pci0 dev 16 function 0 "Intel 82559ER" rev 0x09, i82559S: irq 5, address 00:a0:8e:21:88:9a inphy2 at fxp2 phy 1: i82555 10/100 PHY, rev. 4 pcib0 at pci0 dev 18 function 0 "Cyrix Cx5530 South" rev 0x30 "Cyrix Cx5530 SMI" rev 0x00 at pci0 dev 18 function 1 not configured pciide0 at pci0 dev 18 function 2 "Cyrix Cx5530 IDE" rev 0x00: no DMA, channel 0 wired to compatibility, channel 1 wired to compatibility pciide0: channel 0 ignored (other hardware responding at addresses) pciide0: channel 1 ignored (not responding; disabled or no drives?) "Cyrix Cx5530 XpressAUDIO" rev 0x00 at pci0 dev 18 function 3 not configured isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard wdc0 at isa0 port 0x1f0/8 irq 14 wd0 at wdc0 channel 0 drive 0: wd0: 16-sector PIO, LBA, 9590MB, 19640880 sectors wd0(wdc0:0:0): using BIOS timings pcppi0 at isa0 port 0x61 midi0 at pcppi0: spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pccom0: console pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo biomask f3c5 netmask ffe5 ttymask ffe7 pctr: no performance counters in CPU dkcsum: wd0 matches BIOS drive 0x80 root on wd0a rootdev=0x0 rrootdev=0x300 rawdev=0x302 #
OpenBGP / OpenBSD 3.8 on WRAP and VMware 5.5.1
OpenBGP really rocks - shall send a few six packs to Sechelt rapids for your next Hackaton there - thanks guys! My upstream IP transit provider was a bit surprised when he learned that his shining Cisco 7xxx is eBGP peering - incl. MD5 sums! - since about one month to a mighty old Compaq desktop with a Pentium-III 450 MHz and 256 MByte RAM... Today, I tried to setup a iBGP peering session to that PC running OpenBSD 3.8. I started with a virtual machine also using OpenBSD 3.8 as guest OS in VMware 5.5.1 on a SuSE 10.0 host. The iBGP peering sessions come up nicely, but always die after the Holdtime expires. tcpdump shows that from the VMware machine no BGP Keepalives are originated nor answered. Which causes the BGP peering sessions to go down while, or shortly after (depending on the Holdtime setting), receiving the full feed updates. However, it looks like this problem is not specific to OpenBGP. Because I observe that 'top' does not update the display at all, even though it accepts keyboard commands. So far I was unable to determine the cause for this behaviour, nor find any other problem reports about such problems running OpenBSD in VMware. So I moved my /etc/bgp.conf over to a WRAP1E (Geode 266 MHz, 128 MByte RAM) which runs OpenBSD 3.8 too. Amazing, bgpd runs now since a few hours on this plattform. Like you documented before for Soekris boards, a full feed with about 172k prefixes uses not more than 7 MByte RAM, and the CPU load is close to 0% once the initial updates were received after startup. Is there anyone out there who is willing to provide me with a second BGP4 full feed for a few weeks? I'd love to see the RIB selection in action and document some measurements! In exchange, I can offer a full feed from AS8220 out of Switzerland (filtered to provde "read-only" updates, of course, with or without MD4 sum). Thanks, Rolf
Re: Debugging pxeboot on WRAP
Good news - my WRAPs now pxeboot OpenBSD as expected! The culprit was not pxeboot, but the etherboot PXE code 5.3.12 in BIOS 1.08 and 1.10, as supplied by PCengines. After building an etherboot 5.4.1 binary on rom-o-matic.org, merging it into the BIOS and flashing the WRAPs, network boot of OpenBSD now works very nicely :-) I'll document that a bit more in detail in order to wrap up this thread, and to inform PCengines that OpenBSD can easily network boot. Thanks to all who replied, notably to Marc who triggered me to try replacing the etherboot code in the BIOS, Rolf
Re: Debugging pxeboot on WRAP
Another OpenBSD on WRAP user wrote to me saying that pxeboot works. Also, I found http://www.ultradesic.com/?section=43 which descripbes PXE booting OpenBSD for the Soekris plattform which is very similar to WRAP. Both encouraged me to dig deeper: a) pxeboot finds both labels '!PXE' and 'PXENV' in the BIOS code; b) the checksums of both those BIOS section are OK, e.g. PXE code in the BIOS appears to be intact; c) forcing pxeboot to use the legacy PXENV (instead of the !PXE v2.1) API results in pxe_call() to return OK. (forced by commenting out the line " bang = 1; " in /sys/arch/i386/stand/libsa/pxe.c) However, it appears that result fields of those calls are filled with zero. Because calls of pxeinfo() returns with IP addresses and netmask as 0.0.0.0, instead of DHCP client & server addresses. d) Upgrading WRAP's BIOS from 1.08 to 1.10 did not make any difference. Notably finding c) encouraged me to also question my DHCP server configuration, which currently is: host wrap { hardware ethernet 00:0d:b9:01:a0:a4; option host-name "wrapobsd"; fixed-address 10.0.0.20; next-server 10.0.0.3; option root-path "10.0.0.3:/tftpboot"; filename "/pxeboot"; } Just to crosscheck the PXE capability of WRAP's BIOS, I also tried to load pxegrub from GRUB as 2nd stage boot loader, instead of pxeboot from OpenBSD. So far, pxegrub gets loaded, but I do not get any GRUB prompt yet (something with serial console port parameters might still be wron in my GRUB configure). Any suggestions warmly welcome, Rolf
Re: Debugging pxeboot on WRAP
On 12/26/05, Tom Cosgrove <[EMAIL PROTECTED]> wrote: > You could find out if pxe_call works at all on the WRAP in its current > implementation by putting a printf() after it, and seeing if there' > any output. Look in pxe.c:pxe_init(). Thanks, did that and definitely pxe_call() never returns. And it is not specific to pxe_call(PXENV_GET_CACHED_INFO), because I also called pxeinfo() which does a pxe_call(PXENV_UNDI_GET_NIC_TYPE) which never returns neither! As you say, it looks like I might have to refresh rusty gdb skills now, and figure out what 'boch' does (as I am totally inexperienced with baby sitting ;-) Rolf
Re: Debugging pxeboot on WRAP
> Ah yes, according to CVS log > > http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/stand/libsa/pxe_call.S > that real/protected mode problem should be patched since v1.2. > > But did current v1.3 eventually break it again? Replacing pxe_call.S v1.3 by v1.2 does unfortunately not solve the problem of pxe_call() never returning. Rolf
Re: Debugging pxeboot on WRAP
The posting http://www.monkey.org/openbsd/archive2/bugs/200503/msg1.html is interesting, as it points out that there has already been a problem with pxe_call. > single-stepping back into pxeboot. Five instructions later, I hit the > lockup point at 4012:403c. The instruction causing the problem is: > > addrsize opsize lgdt [ds:0x45e80] > > which is the line marked "Load the GDT" in the following code from > pxe_call.S in the OpenBSD source: > > /* >* real_to_prot() >* >* Switch the processor back into protected mode. >*/ > .globlreal_to_prot > real_to_prot: > .code16 > > xorw %ax, %ax > movw %ax, %ds/* Load %ds so we can get at Gdtr */ > data32 addr32 lgdt Gdtr /* Load the GDT */ > ... > > Note the address [ds:0x45e80] that this resolves to in the pxeboot binary. > In particular, note that the offset contains five hexadecimal digits. > We're allegedly in real-mode at this point. We can't access more than 64k > in each segment, yet this instruction is trying to access data at an > offset of approximately 279k. The CPU doesn't like this. Not sure whether this issue was fixed in OpenBSD yet. That code in OpenBSD3.8 is /sys/arch/i386/stand/libsa/pxe_call.S ... /* * real_to_prot() * * Switch the processor back into protected mode. */ .globl real_to_prot real_to_prot: .code16 movw$LINKADDR >> 4, %ax /* We're linked to LINKADDR/16: */ movw%ax, %ds data32 addr32 lgdt (Gdtr - LINKADDR)/* Reload the GDT */ movl%cr0, %eax /* Enable protected mode */ orl $CR0_PE, %eax movl%eax, %cr0 data32 ljmp $S32TEXT, $r2p32 /* Reload %cs, flush pipeline */ r2p32: .code32 /* Reload 32-bit %ds, %ss, %es */ movl$S32DATA, %eax mov %ax, %ds mov %ax, %ss mov %ax, %es ... Ah yes, according to CVS log http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/stand/libsa/pxe_call.S that real/protected mode problem should be patched since v1.2. But did current v1.3 eventually break it again? Rolf
Re: Debugging pxeboot on WRAP
After inserting some printf() debug statements into /sys/arch/i386/stand/libsa/pxe.c I found that the call to the assembler subroutine pxe_call(PXENV_GET_CACHED_INFO); never returns. It looks like either there is something wrong with that call, or with the PXE code from Etherboot. Rolf
Re: Debugging pxeboot on WRAP
On 12/26/05, J.C. Roberts <[EMAIL PROTECTED]> wrote: > Have you tried bsd.rd ? Just tried it, but pxeboot does not continue to boot either. tcpdump on the TFTP server reveals that the WRAP's PXE client actually requests and loads the pxeboot file, but does not get that far where it would request the kernel file bsd or bsd.rd. Now trying to understand the various debug switches in the Makefile, hoping that they will reveal more output before the WRAP freezes. Rolf
Re: Debugging pxeboot on WRAP
On 12/26/05, J.C. Roberts <[EMAIL PROTECTED]> wrote: > >01F0 - no drive found ! > > > > >My /tftpboot/bsd should be ok as the same kernel file boot ok from a > >CompactFlash card. > > Should we assume you have removed the CompactFlash device? Yes, the CF card is removed, as someone trying PXE on Soekris experienced problems when there was a such drive. But, although the "01F0 - no drive found !" error disappears after inserting a bootable CF card, the pxeboot process still freezes. > Have you tried bsd.rd ? No, not yet. Will try that now, even though I expect that it might not work as it was probably built for GENERIC machine and not for a WRAP that uses an National SC1100 'Geode' ? Rolf
Debugging pxeboot on WRAP
pxeboot from OpenBSD3.8 (but also from 3.5, 3.6. and 3.7) fails to PXE boot WRAP appliances with BIOS 1.08 which supports PXE using etherboot (see www.pcengines.ch): PC Engines WRAP.1C/1D/1E v1.08 640 KB Base Memory 130048 KB Extended Memory 01F0 - no drive found ! ROM segment 0xe000 length 0x8000 reloc 0x0002 Etherboot 5.3.12 (GPL) http://etherboot.org Drivers: NATSEMI Images: NBI PXE Exports: PXE Relocating _text from: [00089370,0009b230) to [07eee140,07f0) Boot from (N)etwork (D)isk or (Q)uit? N Probing pci nic... [dp83815] natsemi_probe: MAC addr 00:0D:B9:01:A0:A4 at ioaddr 0X1000 natsemi_probe: Vendor:0X100B Device:0X0020 dp83815: Transceiver default autoneg. enabled, advertise 100 full duplex. dp83815: Transceiver status 7869 advertising 05E1 dp83815: Setting half-duplex based on negotiated link capability. Searching for server (DHCP)... Me: 10.0.0.20, Server: 10.0.0.3, Gateway 10.0.0.1 Loading 10.0.0.3:pxeboot (PXE)done probing: pc0 com0 pci pxe![2.1] <--- the cursor stays here Searching the Web also for Soekris (which is similar to WRAP) hints that the "A20 gate hack" may be the culprit for this halt. Therefore tried to patch /sys/arch/i386/stand/libsa/gateA20.c so that it leaves the A20 gate alone, even though it seems to be already patched as outlined in http://blog.gmane.org/gmane.os.netbsd.devel.embedded/month=20050601 and in NetBSD3 http://releng.netbsd.org/cgi-bin/req-3.cgi?show=504 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/i386/stand/lib/gatea20.c Then I rebuilt pxeboot: cd /sys/arch/i386/stand make scp /usr/src/sys/arch/i386/stand/pxeboot/pxeboot [EMAIL PROTECTED]/tftpboot/ Still, the boot process halts in the 'probing' line, right after 'pxe![2.1]' My /tftpboot/bsd should be ok as the same kernel file boot ok from a CompactFlash card. My /tftpboot/etc/boot.conf is: set tty com0 stty com0 38400 boot tftp:/bsd Do you have any suggestion how I could debug or prevent this freeze, for example by using debug compile flags in the Makefile, etc.? Thanks for any suggestions, Rolf