Re: Route next-hop interface behaviour
On Sun, Mar 31, 2013 at 08:32:19PM +0100, Richard Tector wrote:
| Hi,
|
| I'm not sure if it is expected behaviour but when configuring a static
| route (default or otherwise) the outbound interface recorded in the
| table does not update when the system's IP changes interface, even when
| removing and re-adding it.
|
| Fairly simple topology, system running 9.1-STABLE (30th March) with just
| one of four 'em' interfaces in use - em0 with 10.0.2.199. Default route
| to 10.0.2.1.
|
| Whilst troubleshooting some odd TCP behaviour I thought I'd try a
| different interface and so downed the active interface and brought up
| one on a PCI card, and swapped the cable over:
|
| # ifconfig em0 down
| # ifconfig em2 inet 10.0.2.199/24
| # ifconfig em2 up
|
| #
| If I then ping an external host it shows as the destination network
| being inaccessible:
|
| root@daffy:~ # ping 212.23.6.76
| PING 212.23.6.76 (212.23.6.76): 56 data bytes
| ping: sendto: Network is down
|
|
| #
| Can contact the next hop just fine:
|
| root@daffy:~ # ping 10.0.2.1
| PING 10.0.2.1 (10.0.2.1): 56 data bytes
| 64 bytes from 10.0.2.1: icmp_seq=0 ttl=64 time=0.211 ms
|
|
| #
| Routing table shows that the default route is still bound to em0 even
| though the next hop is on em2:
|
| root@daffy:~ # netstat -rfinet -n
| Routing tables
|
| Internet:
| DestinationGatewayFlagsRefs Use Netif Expire
| default10.0.2.1 UGS 0 3141em0
| ^^^
| 10.0.2.0/24link#4 U 1 255em2
| 10.0.2.199 link#1 UHS 10lo0
| 127.0.0.1 link#9 UH 00lo0
|
|
| #
| Removing the default route and re-adding also leaves it on the old
| interface:
|
| root@daffy:~ # route delete default
| delete net default
| root@daffy:~ # route add default 10.0.2.1
| add net default: gateway 10.0.2.1
| root@daffy:~ # netstat -rfinet -n
| Routing tables
|
| Internet:
| DestinationGatewayFlagsRefs Use Netif Expire
| default10.0.2.1 UGS 00em0
| 10.0.2.0/24link#4 U 0 688em2
| 10.0.2.199 link#1 UHS 10lo0
| 127.0.0.1 link#9 UH 00lo0
|
| I can understand the initial problem, but surely when I re-add the route
| it should do a lookup against the table for the next hop, ie.
| 10.0.2.0/24, and use the associated Netif?
|
| What's interesting is that if I remove the IP configuration from em0 it
| removes the default route above (even though the interface is downed).
| Re-adding the route works.
You can try this patch:
Index: net/if.c
===
--- net/if.c(revision 248707)
+++ net/if.c(working copy)
@@ -1532,6 +1532,8 @@
IFNET_RLOCK_NOSLEEP();
TAILQ_FOREACH(ifp, &V_ifnet, if_link) {
+ if ((ifp->if_flags & IFF_UP) == 0)
+ continue;
IF_ADDR_RLOCK(ifp);
TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) {
if (ifa->ifa_addr->sa_family != addr->sa_family)
@@ -1620,6 +1622,8 @@
IFNET_RLOCK_NOSLEEP();
TAILQ_FOREACH(ifp, &V_ifnet, if_link) {
+ if ((ifp->if_flags & IFF_UP) == 0)
+ continue;
if ((ifp->if_flags & IFF_POINTOPOINT) == 0)
continue;
IF_ADDR_RLOCK(ifp);
@@ -1672,6 +1676,8 @@
*/
IFNET_RLOCK_NOSLEEP();
TAILQ_FOREACH(ifp, &V_ifnet, if_link) {
+ if ((ifp->if_flags & IFF_UP) == 0)
+ continue;
IF_ADDR_RLOCK(ifp);
TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) {
char *cp, *cp2, *cp3;
Index: net/if_ethersubr.c
===
--- net/if_ethersubr.c (revision 248707)
+++ net/if_ethersubr.c (working copy)
@@ -812,6 +871,11 @@
#if defined(NETATALK)
struct llc *l;
#endif
+ /* Discard packet if interface is not up */
+ if ((ifp->if_flags & IFF_UP) == 0) {
+ m_freem(m);
+ return;
+ }
KASSERT(ifp != NULL, ("%s: NULL interface pointer", __func__));
The issue is that the routing doesn't look to see if the NIC is
up or not. It just looks at the IP address. So it tries to send
it out the first matching NIC that could be down.
Doug A.
Index: net/if.c
===
--- net/if.c (revision 248707)
+++ net/if.c (working copy)
@@ -1532,6 +1532,8 @@
IFNET_RLOCK_NOSLEEP();
TAILQ_FOREACH(ifp, &V_ifnet, if_link) {
+ if ((ifp->if_flags & IFF_UP) == 0)
+ continue;
IF_ADDR_
Re: bce(4) on the Dell PE 2950
On Fri, Apr 12, 2013 at 02:09:04PM -0700, Xin Li wrote: | (Added David to Cc) | | On 04/12/13 13:56, Sean Bruno wrote: | > A note from cluster...@freebsd.org | > | > It looks like there is some amount of instability or bugginess in | > some of the Broadcom firmware(management) on the bce(4) chipeset | > shipped on later generations of the Poweredge 2950 from Dell: | > | > bce0: | > | > Specifically, we've seen that newer (9 and higher) have issues with | > the doing initial setup and negotiation and that Dell did indeed | > release newer firmware to fix the issues. This requires a full | > reboot into Linux (probably centos6) to get the update to execute. | | I could be wrong but I *think* that the firmware is loaded on device | initialization, so there may be a chance that the driver can do it | when starting? Additionally, maybe one can leverage the kernel | firmware(9) framework so that the firmware can be more easily updated | by user? What we created at work was a tool to dump the NIC's "firmware" via the BCE_DEBUG and BCE_NVRAM_WRITE_SUPPORT. It's totally unsupported but works well :-) The usage is to flash it via Linux etc, boot FreeBSD then dump the NVRAM contents. Then use a "flashing" tool that first saves the MAC address info, write the new image and then restore the MAC address ... otherwise all of your NICs get the same MAC addresses! If someone wants to make a decent tool out of it let me know. It's hacky but works. This is why we added the BCE_NVRAM_WRITE_SUPPORT. This means you need these options enabled in the kernel. It's trivial code based on public data. I tossed it up at: http://www.ambrisko.com/doug/bce_firmware.c It needs a correct usage :-) -r reads the NVRAM and -w writes it. There is no error checking "flashing" the firmware since it isn't done via the chip so if you write trash, then you break your NIC. It's a starting point. I put a header file up at: http://www.ambrisko.com/doug/bce_struct.h We've had issues with bce(4) devices since day one in which the BIOS, BMC and NIC firmware had to be in some type of sync. or things break. For a while we actually had to use a cobbled together NIC firmware image from a couple of releases of firmware. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: problem with vlan interfaces tagging/untagging in a simulated switch box
saeedeh motlagh writes: | i think i have similar problem too. you want to have tagged and | untagged traffic at the same time on the trunk port, right? | in your topology the vlans and trunk port are bridged and the tagged | traffic is passed through the trunk port and every thing works fine. | then when you want to have the untagged traffic on the trunk port, | you bridge an interface with trunk port directly. after that all the | traffic which is received on the trunk port, are sent to this | interface and vlans receive no packet. | | eth0 -+ || | eth1 -+ --- bridge1 --- vlan9 --+-- eth4 - | | | eth2 -+ --- bridge2 --- vlan8 --+ + | | eth3 -+ bridge3 + | | please let me know if i understand what you exactly mean. | yours, I think part of the problem with the standard code paths unless you use netgraph is that the vlan SW stack transmits directly to the NIC and skips the bridge. This code is in vlan_start of sys/net/if_vlan.c. There is a comment that says: Send it, precisely as ether_output() would have. Also this would only work with SW VLAN and not HW assist VLAN. So I have two changes, disable HW assist VLAN and to re-insert the VLAN packet into the ether_output just before the bridge. I ended up splitting ether_output into 2 function so I could call the end part of ether_output from vlan_start. I also had a trivial change to allow VLAN in VLAN. I don't really have to use this code now so I've dropped some of it. I did it for testing. Now I plan to create the same test environment using the vimage work since it is cleaner and easier to understand. My suggestion would be to create a netgraph solution since it shouldn't have these limitations. It's probably what I would have done if netgraph had this as the time. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
IPv6 ifconfig down/up issue versus IPv4
Recently, I ran into a problem in which IPv4 works fine but IPv6 doesn't.
I use a trick to "fail-over" NICs via ifconfig down the bad link and then
ifconfig up the good link. Both NICs have the same IP. The 2nd IP is
assigned when the 1st NIC is down. This works fine with IPv4 since on down
it removes the NIC's local route that was set when the IP was assigned ie.
the /x network. In the IPv4 stack it calls if_up and if_down to purge the
route and if_up to recreate the NIC's route. Only when you delete the
IP does the route go away.
This doesn't happen with IPv6, instead the route is created when
the NIC is first assigned an IP and persists when the NIC is down
and even when another is up.
You can see this with route get or netstat -r pointing to a NIC that
doesn't exist.
I have a prototype/first hack to fix it by modeling the IPv4 paradigm and
deal with the routes/multicast groups. I'd like someone to take a look
and tell me what I messed up and how it should be done better.
This appears to be a fairly simple bug in FreeBSD that was just never
looked at before since it is a bit of a corner case.
A lot of this problem can be seen tested via
netstat -r
ndp -a
ifmcstat
Thanks,
Doug A.
diff -upr ../src/sys/net/if.c sys/net/if.c
--- ../src/sys/net/if.c 2009-07-27 12:48:10.0 -0700
+++ sys/net/if.c2011-05-17 12:51:38.0 -0700
@@ -1449,6 +1449,9 @@ if_unroute(struct ifnet *ifp, int flag,
carp_carpdev_state(ifp->if_carp);
#endif
rt_ifmsg(ifp);
+#ifdef INET6
+ in6_if_down(ifp);
+#endif
}
/*
diff -upr ../src/sys/netinet6/in6.c sys/netinet6/in6.c
--- ../src/sys/netinet6/in6.c 2009-07-27 12:48:10.0 -0700
+++ sys/netinet6/in6.c 2011-05-17 12:59:27.0 -0700
@@ -132,6 +132,9 @@ static void in6_unlink_ifa(struct in6_if
struct in6_multihead in6_multihead;/* XXX BSS initialization */
int(*faithprefix_p)(struct in6_addr *);
+static int in6_join_multicast_groups(struct ifnet *ifp,
+ struct in6_aliasreq *ifra, struct in6_ifaddr *ia, int flags,
+ int hostIsNew);
/*
* Subroutine for in6_ifaddloop() and in6_ifremloop().
@@ -788,6 +791,7 @@ in6_control(struct socket *so, u_long cm
return (0);
}
+
/*
* Update parameters of an IPv6 interface address.
* If necessary, a new entry is created and linked into address chains.
@@ -802,10 +806,6 @@ in6_update_ifa(struct ifnet *ifp, struct
struct in6_ifaddr *oia;
struct sockaddr_in6 dst6;
struct in6_addrlifetime *lt;
- struct in6_multi_mship *imm;
- struct in6_multi *in6m_sol;
- struct rtentry *rt;
- int delay;
char ip6buf[INET6_ADDRSTRLEN];
/* Validate parameters */
@@ -1049,6 +1049,41 @@ in6_update_ifa(struct ifnet *ifp, struct
* not just go to unlink.
*/
+ if ((error = in6_join_multicast_groups(ifp, ifra, ia, flags,
hostIsNew))) {
+ goto cleanup;
+ }
+
+
+ return (error);
+
+ unlink:
+ /*
+* XXX: if a change of an existing address failed, keep the entry
+* anyway.
+*/
+ if (hostIsNew)
+ in6_unlink_ifa(ia, ifp);
+ return (error);
+
+ cleanup:
+ in6_purgeaddr(&ia->ia_ifa);
+ return error;
+}
+
+static int
+in6_join_multicast_groups(struct ifnet *ifp, struct in6_aliasreq *ifra,
+ struct in6_ifaddr *ia, int flags, int hostIsNew)
+{
+ int error = 0;
+ struct in6_multi_mship *imm;
+ struct rtentry *rt;
+ struct in6_multi *in6m_sol;
+ int delay;
+ char ip6buf[INET6_ADDRSTRLEN];
+
+/* Up the interface */
+ifp->if_flags |= IFF_UP;
+
/* Join necessary multicast groups */
in6m_sol = NULL;
if ((ifp->if_flags & IFF_MULTICAST) != 0) {
@@ -1263,7 +1295,7 @@ in6_update_ifa(struct ifnet *ifp, struct
ip6_sprintf(ip6buf, &mltaddr.sin6_addr),
if_name(ifp), error));
goto cleanup;
- }
+ }
LIST_INSERT_HEAD(&ia->ia6_memberships, imm, i6mm_chain);
#undef MLTMASK_LEN
}
@@ -1306,20 +1338,8 @@ in6_update_ifa(struct ifnet *ifp, struct
nd6_dad_start((struct ifaddr *)ia, delay);
}
+ cleanup:
return (error);
-
- unlink:
- /*
-* XXX: if a change of an existing address failed, keep the entry
-* anyway.
-*/
- if (hostIsNew)
- in6_unlink_ifa(ia, ifp);
- return (error);
-
- cleanup:
- in6_purgeaddr(&ia->ia_ifa);
- return error;
}
void
@@ -1727,7 +1747,7 @@ in6_ifinit(struct ifnet *ifp, struct in6
/* we could do in(6)_socktrim here, but just omit it at this moment. */
- if (newhost && nd6_need_cache(ifp) != 0) {
+ if (newhost) {
/*
* set the rtrequest function to create llinfo. It also
* adjus
Re: svn commit: r198994 - in stable/6/sys/dev: bce mii
pluknet writes:
[ Charset ISO-8859-1 unsupported, converting... ]
| 2009/11/6 Doug Ambrisko :
| > Author: ambrisko
| > Date: Fri Nov ?6 17:58:44 2009
| > New Revision: 198994
| > URL: http://svn.freebsd.org/changeset/base/198994
| >
| > Log:
| > ?MFC: Merge in minimal 5709/5716 support into 6.X extracted from current.
| > ?This is not a direct merge since I tried to only extra the changes to
| > ?support the 5709 from all of the other changes that have happened in
| > ?head. ?This should not introduce any issues that the other changes may
| > ?have caused. ?We have been running this code for months on Dell r710's.
| > ?It has been lightly tested on systems with 5716's.
| >
| > ?This is to allow people to run newer hardware on 6.X.
|
| Very nice. Thank you.
|
| I'm afraid not all the chunks were merged since I cannot run on 6.x
| with my BCM5709.
|
| FreeBSD 7.2 - works
| FreeBSD 6.4-stable - does not
|
| It locks up somewhere in the late stage of multiuser (usually in a
| random step of rc.d) and getty cannot take the control.
| Here it still pings via network, I can achieve ssh stage where ssh
| warns me "The authenticity of host '$HOST' can't be established."
| If I type "yes", then it stops here and no go. After return from ddb
| it stops even ping until next reboot.
|
| I use boot via NFS/PXE, so it may interfere there, since rc.d usually
| write something to disk, which is NFS-mounted here.
| So it probably could run fine if booting from a local disk (I can't
| test this setup).
You might try to instrument the rc stuff even though you mention it
appears random. Might try to make sure that it isn't re-initializing
the network or something like that. I tried with a fresh checkout
of 6-stable and I PXE booted it fine. A side note is that Dell's
have a bug with their uarts starting with the 2950 rev 2 in which
the TX does work with the speed that we do the reset. RX works
fine so you can recover it with a {Ctrl}d since it doesn't always
fail.
| I've attached dmesg (doesn't differs much from 7.2) and some ddb output below.
| Looking in alltrace I see no obvious lockups, no nfs stuck. But
| sometimes sh stucks somewhere in nfsreq.
|
| The same box boots fine via NFS on different NFS setup with 7.2,
| a different (in h/w) box boots fine on these NFS setup and NFS root,
| so no mistakes in setup part.
|
| I remember that back to August I tried to boot 6.4 with what is in bce
| of RELENG_7 on this box and it booted fine and I xmitted some traffic
| with it.
| So I guess the problem is in NFS-boot.
|
| I'll try to find ways to boot the system locally and report back..
I didn't see anything in the logs.
Doug A.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Vimage virtual networking and 7.0
Bruce M. Simpson writes: [snip] | My concern is that vimage may be a very intrusive change indeed where | these matters are concerned, unless the vimage patches are being kept | up-to-date and regression tested as issues are resolved and new features | added. Just like it was mostly working in 4.X then never worked with 5.X & 6.X and now it sounds like it is working in 7.X but will it be working in 8.X etc? That's a lot of effort he is putting in to keep going dead. Note this comment is based on out-side observation. I know a few people that used it in 4.X. I played with it bit. Yes, it would help IronPort. I'd rather not have to keep merging it. I'm not involved in with the FreeBSD network folks to know the scope and the missing bits. IronPort might be able to help somewhat to accelerate it. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about bce driver
Tom Judge writes: | Julian Elischer wrote: | > Tom Judge wrote: | >> Josh Paetzel wrote: | >>> On Wednesday 11 July 2007, Tom Judge wrote: | Hi Paul, | | From the testing that I have been doing for the last few months | the driver in 6.2 is stable if you are not using jumbo frames and | there is a light-moderate network load. | | However if you want to use Jumbo frames the driver is very | unstable. I posted a patch against 6.2 which should fix some load | based issues in the driver with standard frame sizes. | | Tom | >>> | >>> Paul, I was never able to solve the link up/link down problems with | >>> the driverI was using the drivers from STABLE for a while, and | >>> without jumbo frames everything worked somewhat ok most of the | >>> timethe ultimate solution was to just get the intel PCI-X card | >>> and stop using the broadcoms. | >>> | >>> | >> | >> We have basically come to the same conclusion today, unfortunately | >> this is 35 machines, but if it makes them stable at least we can use | >> them. | > | > I'm not seeing any problems on our 2950s running 6.1 plus some backpatches. | | I am very surprised at that. The driver in 6.1 was un-usable in our | environment. 6.2 makes it usable with standard frames under moderate | load. However use jumbo frames and it all falls apart, and unfortunately | the network these systems are plugged into is GigE only with a 8192 | Jumbo mtu. There are several back-ports/patches in our 6.1 image that we are running! Also we don't do jumbo packets. It wouldn't surprize me if there were jumbo packets issues. Other drivers have had issues with that at certain sizes. What Julian is really saying, is that for our work-load and version of the bce driver things are pretty darn stable. None of our patches are private and are from various versions that have been in -current etc. (ie. pre-Serdes support). There is one possibility in that our IPMI support might be ahead of what is in -current. I forget. IPMI WRT to Broadcom can be "tricky" and cause issues at the PHY level. | I have been trying to get some help with the problem for over a month | now without luck. Firstly I was asked to enable some debugging in the | driver, this just uncovered what seems to be memory management bug in | the driver. A patch was suggest for this but it did not solve the | problem. Next I noticed the NetBSD guys had we written the offending | parts of code which I then ported to FreeBSD driver. Still no luck, | although the problem was not as bad as before. Then I took a look at | the OpenBSD driver, and it seems that they just completely disabled | jumbo frames as they are just so ropey. | | If a patch was released today that fixed the problem then I may be able | to fully test the driver and not have to replace the NIC's. However I am | running out of time with deployment deadlines and I need this kit in | production by the latest mid next week. Which is reasonable unless you have the time to try to really dig in and try to isolate the problem with the firmware or the driver (ie. hack on the driver). Unfortunately you are blazing into uncharted teritory with the bce driver. David has done some great work getting it to work under FreeBSD in what looks to me as his spare time. Things are improving all of the time. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panic in rt_check
Ivan Voras writes:
-- Start of PGP signed section.
[ Charset UTF-8 unsupported, converting... ]
| Hi,
|
| I have a machine that panics almost daily in route.c, in rt_check().
| This panic has been reported by several users, including Marcel
| Moolenaar for a machine in freebsd.org.
|
| The problem is present in both 6-STABLE and 7-CURRENT, and apparently it
| manifests on SMP machines, both i386 and AMD64.
|
| The panic backtrace looks like this:
|
| panic: mtx_lock() of destroyed mutex @ /usr/src/sys/net/route.c:1305
| cpuid = 1
| KDB: stack backtrace:
| db_trace_self_wrapper(c091bcf0,e38b690c,c0659fc1,c093f3cf,1,...) at
| db_trace_self_wrapper+0x26
| kdb_backtrace(c093f3cf,1,c0917de2,e38b6918,1,...) at kdb_backtrace+0x29
| panic(c0917de2,c0925d40,519,0,0,...) at panic+0x111
| _mtx_lock_flags(c5d333a8,0,c0925d40,519,0,...) at _mtx_lock_flags+0x59
| rt_check(e38b6970,e38b698c,c55b7d10,0,0,...) at rt_check+0x11e
| arpresolve(c4e27000,c5d33d98,c50dbe00,c55b7d10,e38b69a6,...) at
| arpresolve+0xaf
| ether_output(c4e27000,c50dbe00,c55b7d10,c5d33d98,ccf8b348,...) at
| ether_output+0x7e
| ip_output(c50dbe00,0,e38b6a1c,0,0,...) at ip_output+0xa09
| tcp_output(ccefbac8,0,c0929785,91d,0,...) at tcp_output+0x1463
| tcp_do_segment(ccefbac8,28,0,1dd,901f,...) at tcp_do_segment+0x1c97
| tcp_input(c6095100,14,c4ea3c00,1,0,...) at tcp_input+0xd5e
| ip_input(c6095100,0,c09258bd,8c,c09efc38,...) at ip_input+0x662
| netisr_processqueue(e38b6cc4,c064df85,c09eb940,1,c4d03480,...) at
| netisr_processqueue+0x98
| swi_net(0,0,c0915aee,471,c4d0bd64,...) at swi_net+0xdb
| ithread_loop(c4d0c270,e38b6d38,c0915862,315,c4d56558,...) at
| ithread_loop+0x1c5
| fork_exit(c063e2d0,c4d0c270,e38b6d38) at fork_exit+0xc5
| fork_trampoline() at fork_trampoline+0x8
|
| ...
|
| #0 doadump () at pcpu.h:195
| 195 pcpu.h: No such file or directory.
| in pcpu.h
| (kgdb) bt
| #0 doadump () at pcpu.h:195
| #1 0xc0659d2c in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
| #2 0xc0659ff0 in panic (fmt=Variable "fmt" is not available.
| ) at /usr/src/sys/kern/kern_shutdown.c:563
| #3 0xc064e699 in _mtx_lock_flags (m=0x0, opts=0, file=0xc0925d40
| "/usr/src/sys/net/route.c", line=1305)
| at /usr/src/sys/kern/kern_mutex.c:178
| #4 0xc06fe28e in rt_check (lrt=0xe38b6970, lrt0=0xe38b698c,
| dst=0xc55b7d10) at /usr/src/sys/net/route.c:1305
| #5 0xc070282f in arpresolve (ifp=0xc4e27000, rt0=0xc5d33d98,
| m=0xc50dbe00, dst=0xc55b7d10, desten=0xe38b69a6 "")
| at /usr/src/sys/netinet/if_ether.c:373
| #6 0xc06f019e in ether_output (ifp=0xc4e27000, m=0xc50dbe00,
| dst=0xc55b7d10, rt0=0xc5d33d98) at /usr/src/sys/net/if_ethersubr.c:175
| #7 0xc07127a9 in ip_output (m=0xc50dbe00, opt=0x0, ro=0xe38b6a1c,
| flags=Variable "flags" is not available.
| ) at /usr/src/sys/netinet/ip_output.c:547
| #8 0xc076d6e3 in tcp_output (tp=0xccefbac8) at
| /usr/src/sys/netinet/tcp_output.c:1125
| #9 0xc076ab87 in tcp_do_segment (m=0xc6095100, th=0xc6095158,
| so=0xccdb67bc, tp=0xccefbac8, drop_hdrlen=40, tlen=0)
| at /usr/src/sys/netinet/tcp_input.c:2345
| #10 0xc076bb0e in tcp_input (m=0xc6095100, off0=20) at
| /usr/src/sys/netinet/tcp_input.c:843
| #11 0xc0710c42 in ip_input (m=0xc6095100) at
| /usr/src/sys/netinet/ip_input.c:663
| #12 0xc06f9148 in netisr_processqueue (ni=0xc09efc38) at
| /usr/src/sys/net/netisr.c:143
| #13 0xc06f925b in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:256
| #14 0xc063e495 in ithread_loop (arg=0xc4d0c270) at
| /usr/src/sys/kern/kern_intr.c:1036
| #15 0xc063b845 in fork_exit (callout=0xc063e2d0 ,
| arg=0xc4d0c270, frame=0xe38b6d38) at /usr/src/sys/kern/kern_fork.c:797
| #16 0xc0896f80 in fork_trampoline () at
| /usr/src/sys/i386/i386/exception.s:205
|
| I've been trying to solve this with Craig Rodrigues, and I've tried
| several patches, without success. The backtrace above happens on the
| following code from net/route.c:
|
| 1299 /* XXX BSD/OS checks dst->sa_family != AF_NS */
| 1300 if (rt->rt_flags & RTF_GATEWAY) {
| 1301 struct rtentry *temp_rt_gwroute = rt->rt_gwroute;
| 1302 if (temp_rt_gwroute == NULL)
| 1303 goto lookup;
| 1304 rt = rt->rt_gwroute;
| 1305 RT_LOCK(rt);/* NB: gwroute */
| 1306 if(rt0->rt_flags & 0x8000U){
| 1307 /*This rt is under process...*/
| 1308 RT_UNLOCK(rt);
| 1309 RT_UNLOCK(rt0);
| 1310 goto try_again;
| 1311 }
| 1312 if ((rt->rt_flags & RTF_UP) == 0) {
| 1313 rt0->rt_flags |= 0x8000U;
| 1314 RTFREE_LOCKED(rt); /* unlock gwroute */
| 1315 rt = rt0;
| 1316 lookup:
| 1317 RT_UNLOCK(rt0);
| 1318 rt = rtalloc1(rt->rt_gateway, 1, 0UL);
| 1319 if (rt == rt0) {
| 1320 rt0->rt_gwroute = NULL;
| 1321 RT_REMREF(rt0);
| 1322 RT_UNLOCK(rt0);
| 1323 return (ENETUNREACH);
|
Re: I/OAT ... Coming Soon ?
Scott Ullrich writes: [ Charset ISO-8859-1 unsupported, converting... ] | On 11/15/07, Doug Ambrisko <[EMAIL PROTECTED]> wrote: | > FWIW, several of us should have motherboards that support it now. | > For example the Dell PE29XX/PE1950 line now has support if you upgrade | > old machines to a newer BIOS and then turn it on in the BIOS setup. | > I'm not sure what em(4) cards support it. So I think hardware should | > be available now. At the time the PE29XX family BIOS did not support it | | I have a stack of Dell 2970's with Intel 1000 cards and will be happy | to test this when a patch is available. Thanks for working on this | Jack! Hmm, I forgot about the 2970 which are AMD based. Can you check the BIOS to see if there is an option to turn it on? I think this is an Intel feature. AMD might have something close? We have one 2970 that we've played with a little but not much. I can't say for sure if it has it. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: I/OAT ... Coming Soon ?
Julian Elischer writes: | Jack Vogel wrote: | > On Nov 14, 2007 5:01 PM, Wilkinson, Alex | > <[EMAIL PROTECTED]> wrote: | >> Hi all, | >> | >> Curious, is I/OAT [http://www.intel.com/go/ioat/] coming to FreeBSD soon | >> ? | > | > LOL, I did a driver for the first version of I/OAT more than a year | > ago, submitted | > it and interest was half hearted. | > | > The driver needs updating and polishing yet, but interest being what it was | > it hasn't been a real high priority. | | I saw what I thought you called a "preliminary" driver. | There was discussion and I thought you got positive but | muted (along the lines of "nice.. when will there be hardware for it?") | and some discussion of how it fits in with TCP offload, but I don't think | that anyone said they didn't like the idea.. FWIW, several of us should have motherboards that support it now. For example the Dell PE29XX/PE1950 line now has support if you upgrade old machines to a newer BIOS and then turn it on in the BIOS setup. I'm not sure what em(4) cards support it. So I think hardware should be available now. At the time the PE29XX family BIOS did not support it :-( Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
vlan & bridging broken since if_vlan directly calls the driver
I found a bug with vlan, netgraph, ipfw and ipfw bridging. The vlan driver
directly calls the HW driver it is associated with on out packets.
If you have a bridge setup it will only send out on the NIC that
the vlan is attached to. It should go out to the bridge and each NIC.
Input works okay.
What I'd like to do is move the netgraph out shim from
if_ethersubr.c:ether_output
/* Handle ng_ether(4) processing, if any */
if (ng_ether_output_p != NULL) {
if ((error = (*ng_ether_output_p)(ifp, &m)) != 0) {
bad:if (m != NULL)
m_freem(m);
return (error);
}
if (m == NULL)
return (0);
}
to ether_output_frame then in if_vlan.c:vlan_start change
IFQ_HANDOFF(p, m, error);
to
ether_output_frame(p, m);
This should make it work correctly and unify the ipfw/netgraph
hooks.
Let me know what you think and then I'll do it.
Thanks,
Doug A.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPMI doesn't work...
Julian Elischer writes: | Jeff wrote: | > I'm not sure what you mean by in band. The IP address of the BMC is | > assigned via the bios and is different from what the OS later | > assigns. With imiptool we can turn on/powercycle/monitor via the BMC | > assigned address up until the point where the kernel loads. Once it | > does, the BMC no longer responds. This doesn't happen with the two | > linux distros we've tried it on. Wtih both, including SuSE, we can | > still query/control via the BMC using ipmitool. It seems to be some | > sort of driver issue to me. I find it confusing that the NIC is | > shared between the BMC and the OS, but I guess that's just how it's | > done. Perhaps the bsd broadcomm driver is simply blocking this | > somehow... | | you have to assign it the same address! Huh? The IPMI IP address and host OS IP address does not have to be the same. I have them set different on the Dell boxes here. They have different MAC addresses. What you mean they have to have the same address? Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPMI doesn't work...
Jeff Behl writes: | that's not the way it's supposed to work, afaik. it'd be silly to tie | the BMC address and the OS assigned address together. you give the BMC | an ip address via a little program that comes from IBM and this address | is independent of the ip address that whatever os you use on the system | assigns to the nic. the redbook that Jung-uk sent a link for shows this | process if you're interested. FYI, you can set the IP configuration for IPMI via ipmitool 1.6. I have a minimal openipmi compatible driver for ipmitool to work on FreeBSD. I need to do some work on it before it can be released. This let's me configure IPMI via FreeBSD without going into the BIOS config tool. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SIOCGIFMEDIA problems
Sebastien Petit writes: | Hi -net hackers, | | A little question about SIOCGIFMEDIA ioctl: | Somebody reports me that some interfaces (bge / em but anothers perhaps) | seem to discard packet(s) during SIOCGIFMEDIA ioctl, Is it true and why ? Doing status checks will cause input/output errors to be reported. I assume that means those packets are lost. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bge BCM5721/BCM5750 fixes to work with IPMI
Here are some first pass patches to make the bge driver not break IPMI.
This was tested on a Dell PE850:
bge0: mem
0xfe6f-0xfe6f irq 16 at device 0.0 on pci4
miibus1: on bge0
brgphy0: on miibus1
brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX,
1000baseTX-FDX, auto
It shouldn't break other bge cards and it might work with other Broadcom
IPMI capable chips (they seem to have different usages). Please let me know
how this goes.
I gleaned this info. from the Linux drivers. YMMV.
Doug A.
Index: if_bge.c
===
RCS file: /usr/local/cvsroot/freebsd/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.94
diff -u -p -r1.94 if_bge.c
--- if_bge.c4 Sep 2005 06:35:59 - 1.94
+++ if_bge.c14 Oct 2005 19:11:11 -
@@ -264,6 +264,11 @@ static int bge_miibus_readreg (device_t,
static int bge_miibus_writereg (device_t, int, int, int);
static void bge_miibus_statchg (device_t);
+#define BGE_RESET_START 1
+#define BGE_RESET_STOP 2
+static void bge_sig_post_reset(struct bge_softc *, int);
+static void bge_sig_legacy(struct bge_softc *, int);
+static void bge_sig_pre_reset(struct bge_softc *, int);
static void bge_reset (struct bge_softc *);
static device_method_t bge_methods[] = {
@@ -1187,6 +1192,78 @@ bge_setmulti(sc)
return;
}
+static void
+bge_sig_pre_reset(sc, type)
+ struct bge_softc *sc;
+ int type;
+{
+ bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER);
+
+ if (sc->bge_asf_mode & ASF_NEW_HANDSHAKE) {
+ switch (type) {
+ case BGE_RESET_START:
+ bge_writemem_ind(sc, BGE_SDI_STATUS, 0x1); /* START */
+ break;
+ case BGE_RESET_STOP:
+ bge_writemem_ind(sc, BGE_SDI_STATUS, 0x2); /* UNLOAD */
+ break;
+ }
+ }
+}
+
+static void
+bge_sig_post_reset(sc, type)
+ struct bge_softc *sc;
+ int type;
+{
+ if (sc->bge_asf_mode & ASF_NEW_HANDSHAKE) {
+ switch (type) {
+ case BGE_RESET_START:
+ bge_writemem_ind(sc, BGE_SDI_STATUS, 0x8001);
+ /* START DONE */
+ break;
+ case BGE_RESET_STOP:
+ bge_writemem_ind(sc, BGE_SDI_STATUS, 0x8002);
+ break;
+ }
+ }
+}
+
+static void
+bge_sig_legacy(sc, type)
+ struct bge_softc *sc;
+ int type;
+{
+ if (sc->bge_asf_mode) {
+ switch (type) {
+ case BGE_RESET_START:
+ bge_writemem_ind(sc, BGE_SDI_STATUS, 0x1); /* START */
+ break;
+ case BGE_RESET_STOP:
+ bge_writemem_ind(sc, BGE_SDI_STATUS, 0x2); /* UNLOAD */
+ break;
+ }
+ }
+}
+
+void bge_stop_fw(struct bge_softc *);
+void
+bge_stop_fw(sc)
+ struct bge_softc *sc;
+{
+ int i;
+
+ if (sc->bge_asf_mode) {
+ bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM_FW, BGE_FW_PAUSE);
+
+ for (i = 0; i < 100; i++ ) {
+ if (!(CSR_READ_4(sc, BGE_CPU_EVENT) & (1 << 14)))
+ break;
+ DELAY(10);
+ }
+ }
+}
+
/*
* Do endian, PCI and DMA initialization. Also check the on-board ROM
* self-test results.
@@ -1284,10 +1361,13 @@ bge_chipinit(sc)
/*
* Set up general mode register.
*/
+
CSR_WRITE_4(sc, BGE_MODE_CTL, BGE_MODECTL_WORDSWAP_NONFRAME|
BGE_MODECTL_BYTESWAP_DATA|BGE_MODECTL_WORDSWAP_DATA|
BGE_MODECTL_MAC_ATTN_INTR|BGE_MODECTL_HOST_SEND_BDS|
BGE_MODECTL_TX_NO_PHDR_CSUM|BGE_MODECTL_RX_NO_PHDR_CSUM);
+ BGE_SETBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP);
+
/*
* Disable memory write invalidate. Apparently it is not supported
@@ -2326,8 +2406,28 @@ bge_attach(dev)
}
}
+ sc->bge_asf_mode = 0;
+ if (bge_readmem_ind(sc, BGE_SOFTWARE_GENCOMM_SIG)
+ == BGE_MAGIC_NUMBER) {
+ if (bge_readmem_ind(sc, BGE_SOFTWARE_GENCOMM_NICCFG)
+ & BGE_HWCFG_ASF) {
+ sc->bge_asf_mode |= ASF_ENABLE;
+ if (CSR_READ_4(sc, BGE_MODE_CTL)
+ & BGE_MODECTL_STACKUP ) {
+ sc->bge_asf_mode |= ASF_STACKUP;
+ }
+ if (sc->bge_asicrev == BGE_ASICREV_BCM5750) {
+ sc->bge_asf_mode |= ASF_NEW_HANDSHAKE;
+ }
+ }
+ }
+
/* Try to reset the chip. */
+ bge_stop_fw(sc);
+ bge_sig_pre_reset(sc, BGE_RESET_STOP);
bge_reset(sc);
+ bge_sig_legacy(sc, BGE_RESET_STOP);
Re: 8021x on wired Ethernet
On Wed, May 16, 2018 at 02:17:21PM +0300, Zeus Panchenko wrote: | Bengt Ahlgren wrote: | > Is there a standard "rc.conf" way to configure 8021x authentication on | > wired ethernet? | | looks like it's to be something like: ifconfig_em0="WPA" Yes for example; ifconfig_em0="WPA " We use 802.1x at work. Doug A. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Etherboot 4.6.1 and FreeBSD 4.2 Release
John Fitzgibbon writes: | For the benefit of fellow-sufferers: | | I figured it out. It was a plain old DOS problem rather than | Etherboot/FreeBSD. | | I took the following lines out of my boot floppy's config.sys: | | device=himem.sys /testmem:off | dos=high,umb | stacks=9,256 | | ... and the kernel boots fine. | | Now I just need to get my conf files sorted | | - Original Message - | From: "John Fitzgibbon" <[EMAIL PROTECTED]> | | > Anyone know if this combination works? | > | > I'm trying to use Etherboot 4.6.1's ne.com, (vanilla compile from the | ports | > collection), to diskless boot a 4.2 Release kernel. | > | > On the client, ne.com recognizes the kernel as FreeBSD/ELF and loads it | from | > the server. However, on switching to the kernel I immediately get the | > following: | > | > Fatal trap 12: page fault while in vm86 mode... | > fault code = user read, page not present... | > panic page fault | > | > ... and I'm hosed. | > | > The kernel is compiled with the BOOTP options, (but it looks like its not | > even loaded properly). | > | > Any suggestions/alternatives would be appreciated. FYI, you can make a bootable floppy without the need for DOS via cd in work/etherboot/src and type gmake bin32/.fd0 That's what I usually do. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: etherboot on a hard disk howto ?
Luigi Rizzo writes: | Hi, | does anyone know how to install etherboot onto a hard disk instead | of a floppy ? | | Plainly copying the floppy image into a slice does not seem | to work (the boot manager does not even let you choose it, despite | it lists the slice as accessible). Unfortunately this is a re-direct. You could try to send this question to [EMAIL PROTECTED] someone might come up with an answer since it is not FreeBSD specific. The other thing you could look at is grub. I see there is a grub in ports (don't know how current) grub uses Etherboot's drivers for it's netboot. I haven't tried it to netboot FreeBSD but that might help or give clues. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: broadcast and aironet PCI4800
Radoslav Vasilev writes: | Hello, I wonder is there a way to connect two phisical networks on ethernel level in |a situation like this: | I have two subnets(subnet1,2) connected through 2 aironet PCI4800 NICs(Cisco Aironet |340 Series) working on gateway1 and 2.(FreeBSD 3.3 and 4.3 machines) | ---\ /- | || |gateway1->---< gateway2<-> |Internet | || | ---/ \- | subnet1subnet2 | | I was told I could try using ProxyARP, but if I do so, I'll manege to make machines |on subnet1(for example) to see subnet2's machines. What I need actually is some kind |of bridging, and I don't know: | 1) can I use bridging(turning on promiscuous mode) on aironet | 2) on gateway2 i have ipfw | As a third suggestion I got the idea of using netgraph. | Allright, I'll appreciate any ideas for what way do you think I should go ahead. | Thanks in advance Seems like you don't have enough information in the picture. If for example subnet1 is 192.168.1 subnet2 is 192.168.2 the wireless gateway is 192.168.3 Internet is something Then this is a pure routing problem. Then learn about routing via "route" However, with -stable (ie after 4.3) there have been changes made to the Aironet driver to do promiscuous on wireless and the submitter of the patch has bridged the wireless and wired network together. In that case you could. subnet1 is 192.168.1 subnet2 is 192.168.1 the wireless gateway is 192.168.1 (bridged to subnet x) Internet is the default route. Then use could use netgraph bridge to tie the wireless adapters to your wired network. It would appear to be one big network. Even without the patches some things using VPN tunnels and bridging could tie stuff together. Really in this case subnet1 & subnet2 are effectively the same network. I haven't personaly done this (except routing) but giving you and idea of what to persue. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Problem with Cisco Aironet 340 series 11mbs Wireless Card
Eric Parker writes: | > Eric Parker said: | > > I tried that, no dice. It appears that the problem is that the | > > interface card isn't initalized yet to accept the ancontrol commands. | > | > Hmmm... I put an ifconfig an0 up in the first line and that let | > things go just fine. I call the script out of pccard.conf. | > | > Not sure why sleeping for 5 secs works... my card would pretty much ignore | > ancontrol until I brought the if up. Think things may have changed | > a little in 4.3. | | No, I just wasn't aware that you had to up the interface, I | thought rc did that prior to running the config for it. As soon as I | added the up command to the start up file, it worked as planned. Thanks! This has been fixed in later versions. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: anyone know where the etherboot page is?
Alfred Perlstein writes: | I'm looking for that site that makes custom etherboot images | via CGI. Anyone have the url? Don't try Sears or late night info-mercials try the one and only rom-o-matic: www.rom-o-matic.net or your local ports tree. Doug eh? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: pcap_open_live() takes 1 sec to complete?
Marco Molteni writes: | I am writing a small program that does a pcap_open_live() on the | Aironet an device, PCMCIA mode. System is a recent -stable on a | Toshiba Portege 7200 laptop. | | Now, pcap_open_live() takes more than 1 sec to return. Is this long | time expected? Hmm, don't seem to recall that. My system is busy doing a make world and stuff. I just tried it and on my busy machine it was less then a second. Note I was not in RFMON mode. It might take longer when I have to switch into RFMON mode. I can try that later. You might try to compare it without RFMON if you are using RFMON. FYI, I put a sample BPF packet dumper up at: http://www.ambrisko.com/doug/an/dump_packet/ I used it to debug the 802.11 packet problem and to look at the raw Aironet Header packets. You'll see it has some test code to check gap length. This is on -stable with my 802.11 aligment fix. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: USB ethernet problem
Thomas Zenker writes: | the situation changed, I have tried to install the new release now | on the final embedded hardware. It is to mention, that this hardware | is working with fbsd 4.3 from july without any problems in about | 50 equipments. Upgrade from the previous fbsd 4.3 works flawlessly | (4.3 kernel is running during this procedure), however after rebooting | the 4.4 kernel, another upgrade run doesn't terminate: | | usb0: host controller process error | usb0: host controller halted Hmm, I've seen this with my usio driver (USB -> serial adapter using the Anchor chip) and couldn't figure it out. It seems to happen more as machines are sharing interrupts with USB on UHCI controllers. Lots of small packets seem to trigger it more. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: pptp + mschap
Brian Somers writes: | I don't know a great deal about PPTP, but as it happens, I recently | looked for a radius server that'd talk MSCHAPv2 - so that I could teach | ppp to do it. | | I couldn't find any support in the ports, and then our [potential] | client backed out, so I never got any further. | | If you could find a spec on how to talk MSCHAP & MSCHAPv2 to a radius | server, I'd certainly be happy to add support to ppp. You never know | - the client may come back :*) FYI, try FreeRADIUS from their cvs tree. It works here for our testing. http://www.freeradius.org/ Now if they supported LEAP ... I think people are working on it. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: How to Update and recompile an device driver
Brooks Davis writes: | On Fri, Feb 08, 2002 at 02:44:31PM -0800, W Alexander Hagen wrote: | > | >Is is possible to cvsup only a device driver. I have tried copying the | >source of the driver and then rebuilding the kernel, but it allways | >seems to invoke dependencies that are assumed to be updated over the | >base 4.3 FreeBSD as well. The latest try I get | > | >if_an.c IFM_IEE80211 undeclared and related messages | | By far, your best bet is to give up now and do an OS upgrade. Updating | drivers independently is a completly unsupported operation for experts | only. The above error means you need to updated your if_media support. | To do that you need to find the commit logs for the upgrades to add | IEEE 802.11 support to if_media and update all the files in question. | There are probalby other things you'd have to update too. ... yep like Linux device private ioctl's and ancontrol changes. You really are better off get the latest -stable and then building everything. Things will work better in the end. Also if you find a problem then getting a fix will be easier as well! Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Adding support for Netgear GA621 (TBI interface)
I've been working on adding support for Netgears GA621 Gigabit Fiber card.
I basically have it working. I'm still trying to refine the link
detection code. I have been able to connect it to some other fiber card
via a cross-over cable and send packets back and forth. I have some more
testing to do when I get a fiber switch that works (first one didn't
work and I'm waiting on a replacement).
Here are patches based on -stable. I'd appreciate someone reviewing the
changes and let me know if I'm going about it in the wrong direction
or if it just needs minor changes. It's definitely a work in progress
at the moment but appears to be functioning fairly well. Some of the
ifmedia stuff I just stumbled through by looking at other drivers.
I will need someone to verify I didn't break the copper verison
since I only have a TBI (fiber) version.
Thanks,
Doug A.
Index: if_ngereg.h
===
RCS file: /cvs/src/sys/dev/nge/if_ngereg.h,v
retrieving revision 1.4.2.2
diff -c -r1.4.2.2 if_ngereg.h
*** if_ngereg.h 19 Sep 2001 23:14:28 - 1.4.2.2
--- if_ngereg.h 18 Feb 2002 21:12:15 -
***
*** 128,133
--- 128,134
#define NGE_CFG_PHYINTR_LNK 0x0008
#define NGE_CFG_PHYINTR_DUP 0x0010
#define NGE_CFG_MODE_1000 0x0040
+ #define NGE_CFG_TBI_EN0x0100
#define NGE_CFG_DUPLEX_STS0x1000
#define NGE_CFG_SPEED_STS 0x6000
#define NGE_CFG_LINK_STS 0x8000
***
*** 420,426
/* TBI BMCR */
#define NGE_TBIBMCR_RESTART_ANEG 0x0200
#define NGE_TBIBMCR_ENABLE_ANEG 0x1000
! #define NGE_TBIBMCR_LOOPBACK 0x4000
/* TBI BMSR */
#define NGE_TBIBMSR_ANEG_DONE 0x0004
--- 421,427
/* TBI BMCR */
#define NGE_TBIBMCR_RESTART_ANEG 0x0200
#define NGE_TBIBMCR_ENABLE_ANEG 0x1000
! #define NGE_TBIBMCR_LOOPBACK 0x4000
/* TBI BMSR */
#define NGE_TBIBMSR_ANEG_DONE 0x0004
***
*** 429,434
--- 430,437
/* TBI ANAR */
#define NGE_TBIANAR_HDX 0x0020
#define NGE_TBIANAR_FDX 0x0040
+ #define NGE_TBIANAR_PS1 0x0080
+ #define NGE_TBIANAR_PS2 0x0100
#define NGE_TBIANAR_PCAP 0x0180
#define NGE_TBIANAR_REMFAULT 0x3000
#define NGE_TBIANAR_NEXTPAGE 0x8000
***
*** 436,441
--- 439,446
/* TBI ANLPAR */
#define NGE_TBIANLPAR_HDX 0x0020
#define NGE_TBIANLPAR_FDX 0x0040
+ #define NGE_TBIANAR_PS1 0x0080
+ #define NGE_TBIANAR_PS2 0x0100
#define NGE_TBIANLPAR_PCAP0x0180
#define NGE_TBIANLPAR_REMFAULT0x3000
#define NGE_TBIANLPAR_NEXTPAGE0x8000
***
*** 656,661
--- 661,668
struct callout_handle nge_stat_ch;
SLIST_HEAD(__nge_jfreehead, nge_jpool_entry)nge_jfree_listhead;
SLIST_HEAD(__nge_jinusehead, nge_jpool_entry) nge_jinuse_listhead;
+ u_int8_tnge_tbi;
+ struct ifmedia nge_ifmedia;
};
/*
Index: if_nge.c
===
RCS file: /cvs/src/sys/dev/nge/if_nge.c,v
retrieving revision 1.13.2.7
diff -c -r1.13.2.7 if_nge.c
*** if_nge.c14 Dec 2001 19:44:38 - 1.13.2.7
--- if_nge.c18 Feb 2002 21:12:15 -
***
*** 620,645
struct mii_data *mii;
sc = device_get_softc(dev);
! mii = device_get_softc(sc->nge_miibus);
! if ((mii->mii_media_active & IFM_GMASK) == IFM_FDX) {
! NGE_SETBIT(sc, NGE_TX_CFG,
! (NGE_TXCFG_IGN_HBEAT|NGE_TXCFG_IGN_CARR));
! NGE_SETBIT(sc, NGE_RX_CFG, NGE_RXCFG_RX_FDX);
} else {
! NGE_CLRBIT(sc, NGE_TX_CFG,
! (NGE_TXCFG_IGN_HBEAT|NGE_TXCFG_IGN_CARR));
! NGE_CLRBIT(sc, NGE_RX_CFG, NGE_RXCFG_RX_FDX);
! }
! /* If we have a 1000Mbps link, set the mode_1000 bit. */
! if (IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_TX ||
! IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_SX) {
! NGE_SETBIT(sc, NGE_CFG, NGE_CFG_MODE_1000);
! } else {
! NGE_CLRBIT(sc, NGE_CFG, NGE_CFG_MODE_1000);
! }
return;
}
--- 620,674
struct mii_data *mii;
sc = device_get_softc(dev);
! if (sc->nge_tbi){ /* DJA check this */
!
! /*
!* BUG: Can't read Link status so assume FDX unless HDX is
!* specified
!*/
! if (IFM_SUBTYPE(sc->nge_ifmedia.ifm_cur->ifm_media)
! == IFM_AUTO) {
! if (CSR_READ_4(sc, NGE_TBI_ANLPAR) & NGE_TBIANAR_FDX) {
! NGE_SETBIT(sc, NGE_TX_CFG,
!
Re: bootp tags used in FreeBSD ?
Luigi Rizzo writes:
| Hi,
| does anyone have up-to-date information on which bootp/dhcp
| tags are used by FreeBSD ?
| I am asking because of two reasons:
|
| + I would like to pass some info from the bootp/dhcp server
|to userland, so they can be used at runtime to customize
|system's behaviour (specific example: I have ~100 clients
|in different labs booting from the same server, where
|configuration should be lab-specific but not host-specific.
|A bootp server could easily pass the "domain" each host
|belong to. I know I could derive this info using the hostname
|as a search key, but this would involve an additional configuration
|file...).
|
| + I was going to fix the bootptab manpage and i see that there are
|several vendor tags used in bootpc_subr and in etherboot
|which are not documented. Even worse, some of those tags are
|not consistent across different systems, and even etherboot
|and bootpc_subr.c have different ideas on T129 and T130
I'd suggest look at isc-dhcp 3 and get dhclient working in a netboot
environment so you can deal with "vendor-class-identifier".
Then just have it do the right things without more over loading
of common things and then run into a collision which there are several.
For example here are parts of my dhcpd.conf file;
option etherboot-freebsd-howto code 132 = integer 32;
option etherboot-kernel-env code 133 = string;
option etherboot-menu-count code 176 = integer 8;
option etherboot-menu-config code 160 = string;
option etherboot-menu-1 code 192 = string;
option etherboot-menu-2 code 193 = string;
option etherboot-menu-3 code 194 = string;
option etherboot-menu-4 code 195 = string;
option etherboot-menu-5 code 196 = string;
option etherboot-menu-6 code 197 = string;
option freebsd-swap-path code 128 = string;
option dhcp-vendor-identifier code 60 = string;
option load-control code 160 = string;
class "etherboot" {
match if substring (option vendor-class-identifier, 0, 9) =
"Etherboot";
option etherboot-menu-count 5;
option etherboot-menu-config "timeout=30:default=192:";
option etherboot-menu-1 "BSD:::/tftpboot/kernel.bsd:";
option etherboot-menu-2 "DOS:::/tftpboot/netdos:";
option etherboot-menu-3 "TEST:::/tftpboot/kernel.test:";
option etherboot-menu-4 "DISK:::/dev/hda";
option etherboot-menu-5 "GRUB:::/tftpboot/nbgrub";
option etherboot-menu-6 "PXE:::/tftpboot/pxeboot";
option etherboot-kernel-env "hw.ata.wc=1";
# option etherboot-freebsd-howto 0x1002; # serial & single
option etherboot-freebsd-howto 0x1000; # serial
# option etherboot-freebsd-howto 0x1800; # serial & verbose
}
class "pxe" {
match if substring (option vendor-class-identifier, 0, 9) =
"PXEClient";
# filename "/tftpboot/pxeboot";
}
class "ambit-load" {
match if option dhcp-vendor-identifier = "Load";
option root-path "ftp://192.168.99.254/ambit-1.5.43-am";;
option load-control "stuff that only this cares";
}
Then in my dhclient.conf (version 3)
option load-control code 160 = string;
send vendor-class-identifier "Load";
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name, root-path, option-160;
and then dhclient-exit-hooks do what I need with the parameters
passed.
I also have a fully working proxyDHCP & bootserver functionality so
I can do menus, DOS boots etc via PXE compliant roms via patches
to isc-dhcp that are on the net.
Now I don't have to worry about bpBatch, Etherboot, PXE, FreeBSD, Linux
all fighting over the same parameter and making the packet to big.
BTW it would be nice to add a Vendor Indentifier to the kernel DHCP
request to filter out just those things.
I think jdp was working on making dhclient not kill the network when
run from a netbooted environment. I forget the status of that.
Doug A.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: recent change to netinet/in.c panics bootp kernels w/ >1 interface
Luigi Rizzo writes:
| As a followup, this seems to fix the problem, if there are no
| objections I am going to commit this soon.
|
| cheers
| luigi
|
|
| > lcvs diff -u bootp_subr.c
| Index: bootp_subr.c
| ===
| RCS file: /home/ncvs/src/sys/nfs/Attic/bootp_subr.c,v
| retrieving revision 1.20.2.7
| diff -u -r1.20.2.7 bootp_subr.c
| --- bootp_subr.c1 Feb 2002 17:22:55 - 1.20.2.7
| +++ bootp_subr.c15 Mar 2002 21:08:16 -
| @@ -1044,10 +1044,11 @@
| ifctx->broadcast.sin_addr.s_addr = sin->sin_addr.s_addr;
|
| error = ifioctl(so, SIOCSIFBRDADDR, (caddr_t)ireq, procp);
| - if (error != 0)
| + if (error != 0 && error != EADDRNOTAVAIL)
| panic("bootpc_fakeup_interface: "
| "set if broadcast addr, error=%d",
| error);
| + error = 0;
|
| /* Get HW address */
|
| @@ -1109,7 +1110,7 @@
| sin = (struct sockaddr_in *) &ireq->ifr_addr;
| clear_sinaddr(sin);
| error = ifioctl(so, SIOCDIFADDR, (caddr_t) ireq, procp);
| - if (error != 0 && (error != EEXIST ||
| + if (error != 0 && (error != EADDRNOTAVAIL ||
|ifctx == gctx->interfaces))
| panic("bootpc_adjust_interface: "
| "SIOCDIFADDR, error=%d", error);
|
| On Fri, Mar 15, 2002 at 01:00:30PM -0800, Luigi Rizzo wrote:
| > The part shown below of a recent commit to in.c (1.60->1.61,
| > MFC'ed as 1.44.2.7 -> 1.44.2.8) always causes a panic when
| > using 'options BOOTP' on a system with more than 1 interface.
| ...
| > This was noticed by Doug Ambrisko who nailed down the problem
| > to this commit.
| >
| > Now, I see two possibilities for a fix here: either move the new
| > block after the EEXIST check (but this would nullify its effects),
| > or add checks in sys/nfs/bootpc_subr.c to ignore errors from
| > ifioctl (the EEXIST is apparently mapped into EADDRNOTAVAIL),
| > as it used to be in the past. Of course, hoping that
| > the "ia->ia_addr = oldaddr;" assignment does not cause other
| > problems.
| >
| > I can work on the latter, the problem is rather critical
| > and urgent to fix as it basically breaks most diskless setups.
That fixes the panic and makes the first interface work. However,
I recall it used to send BOOTP/DHCP request out on all interfaces and
indeed it claims to:
IPsec: Initialized Security Association Processing.
ad0: 19092MB [38792/16/63] at ata0-master UDMA100
Sending DHCP Discover packet from interface sis0 (00:e0:18:50:d5:54)
Sending DHCP Discover packet from interface fxp0 (00:02:b3:39:2f:c8)
bootpc_call: sosend: 51 state
Sending DHCP Discover packet from interface faith0
(00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00)
however, a packet capture via a connect to fxp0 showed that was not the
case. The packets seem to be only going out the first interface. The
others are ignored.
I also seem to have run into a bug with the 630ET support and netbooting
via Etherboot. Linux/Etherboot does
SIS_SETBIT(sc, SIS_CSR, SIS_CSR_ACCESS_MODE);
Adding:
if (sc->sis_rev == SIS_REV_630ET)
SIS_CLRBIT(sc, SIS_CSR, SIS_CSR_ACCESS_MODE);
to the FreeBSD driver fixes this. Seems like FreeBSD driver does not
using this mode or it can't detect the PHYS.
I'm going to do some more tests with this and then commit that.
Doug A.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Review for BOOTP/DHCP Vendor identifier
I put together a patch that adds option 60 to the FreeBSD kernel BOOTP code.
I fill in the vendor indentifier string as:
::
partially based on how NetBSD does it. However, NetBSD uses this format:
::kernel:
I wonder how usefull the "kernel" part is. Should we just do it to
follow suit with NetBSD. I'm thinking we probably should do it the
same way as NetBSD.
Note I started on adding this code and then looked at what NetBSD did.
I can add similar code to the pxeboot loader.
The goal is that via the vendor identifier I can have various OS and
BOOTP/DHCP configured type things get the right info at the right
time and avoid tag conflicts. I think the part would be
useful for those that netboot various different types off one server.
Attached is my patch to -current. After a review I'd like to commit
something like this.
TIA for a review,
Doug A.
Index: bootp_subr.c
===
RCS file: /cvs/src/sys/nfsclient/bootp_subr.c,v
retrieving revision 1.35
diff -u -r1.35 bootp_subr.c
--- bootp_subr.c28 Feb 2002 03:07:35 - 1.35
+++ bootp_subr.c8 Apr 2002 19:44:16 -
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
#include
#include
@@ -203,6 +204,8 @@
#define TAG_DHCP_SERVERID 54
#define TAG_DHCP_LEASETIME 51
+#define TAG_VENDOR_INDENTIFIER 60
+
#define DHCP_NOMSG0
#define DHCP_DISCOVER 1
#define DHCP_OFFER2
@@ -1303,7 +1306,9 @@
struct bootpc_globalcontext *gctx, struct thread *td)
{
unsigned char *vendp;
+ unsigned char vendor_client[64];
uint32_t leasetime;
+ uint8_t vendor_client_len;
ifctx->gotrootpath = 0;
@@ -1328,6 +1333,14 @@
*vendp++ = 2;
*vendp++ = (sizeof(struct bootp_packet) >> 8) & 255;
*vendp++ = sizeof(struct bootp_packet) & 255;
+
+ snprintf(vendor_client, sizeof(vendor_client), "%s:%s:%s",
+ ostype, MACHINE, osrelease);
+ vendor_client_len = strlen(vendor_client);
+ *vendp++ = TAG_VENDOR_INDENTIFIER;
+ *vendp++ = vendor_client_len;
+ memcpy(vendp, vendor_client, vendor_client_len);
+ vendp += vendor_client_len;;
ifctx->dhcpquerytype = DHCP_NOMSG;
switch (ifctx->state) {
case IF_DHCP_UNRESOLVED:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: vlan traffic over ipsec tunnel
Archie Cobbs writes: | Terry Lambert writes: | > Bridging doesn't work with the vlanX interface currently in FreeBSD. | | Why not? | | I believe you, I've just never used vlans and always assumed | that they acted like normal Ethernet interfaces. Same here: a21p# ngctl list There are 5 total nodes: Name: ngctl53375 Type: socket ID: 0006 Num hooks: 0 Name: an0 Type: ether ID: 0005 Num hooks: 0 Name: vmnet1 Type: ether ID: 0004 Num hooks: 0 Name: vlan0 Type: ether ID: 0003 Num hooks: 0 Name: fxp0Type: ether ID: 0002 Num hooks: 0 a21p# ifconfig vlan0 vlan0: flags=8843 mtu 1500 inet 192.168.33.1 netmask 0xff00 broadcast 192.168.33.255 ether 00:10:a4:91:2e:ce vlan: 34 parent interface: fxp0 a21p# Would imply it should just work to bridge vlan's via netgraph bridging. As Archie said I have not tested this to prove how it does or does not work since I haven't had a need to try it. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Fwd: mbuf chain
Luigi Rizzo writes: | On Tue, Sep 24, 2002 at 04:15:56PM -0700, Prafulla Deuskar wrote: | > Sorry for the cross-posting. | > | > | > All, | > | > Is there a pre-set limit on maximum number of fragments in a | > mbuf chain ? | > | > I see 64 fragments with jumboframes (mtu 9000) using nttcp. | | aha... (this is related to the problem with the em driver and jumbo | frames, right ?) | | o limit that i know of. | And now i clearly see how the long chain might arise -- sosend puts | each write in one ro more mbufs, then down in the call chain, | sbappend() is called which in turn calls sbcompress(). The problem | is, for short writes on a TCP socket (say 128 bytes at a time) the | data goes into regular mbufs, not clusters, so sbcompress does not | have a chance to compress the chain because of lack of space in the | mbufs. | | A possible workaround would be to modify sbcompress to allocate | clusters replacing existing mbufs when such a situation exists. Various drivers have code to deal with this when the structure it is putting the frags into runs out :-( See a recent bug fix to the ste(4) gleaned from the fxp(4). This type of problem is probably lurking in other drivers. Unfortunately the ste(4) driver siliently failed and sent out truncated packets before the fix. When I instrumented the code while the system was hosting a CVS pserver checkout I saw the frag count go up to 10. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Fwd: mbuf chain
Luigi Rizzo writes: | On Wed, Sep 25, 2002 at 12:39:45PM -0700, Doug Ambrisko wrote: | ... | > Various drivers have code to deal with this when the structure | > it is putting the frags into runs out :-( See a recent bug fix to | > the ste(4) gleaned from the fxp(4). This type of problem is probably | > lurking in other drivers. Unfortunately the ste(4) driver siliently | | which suggests that we should definitely try to modify sbappend() | and/or possibly sbcompress to reduce the fragment count to reasonably | small values even in presence of very small writes. Sounds good to me. BTW a simple test is to do a "dd" of small writes over rsh/ssh. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Configure wireless connection using Cisco aironet 350
Imrani writes: [ Charset ISO-8859-1 unsupported, converting... ] | Hi, | | I am trying to configure Cisco Aironet 350 wireless PCI card but I | get an error which I am unable to find much details for that. Following | is description of ifconfing: | | > ifconfig an0 | an0: flags=8843 mtu 1500 | inet6 fe80::209:7cff:fe22:6eab%an0 prefixlen 64 scopeid 0x2 | ether 00:09:7c:22:6e:ab | media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) | status: associated | ssid 1:myhome channel 9 | stationname FreeBSD | ano: record length mismatch -- expected 194, got 196 for Rid ff10 | authmode OPEN privacy ON deftxkey 2 txpowmax 0 rtsthreshold 0 | fragthreshold 0 roaming DEVICE | | | As you can see the wireless card is detected and status is "associated' | but my wireless connection doesn't work. I cannot even ping the router. | | Can you please help me configure wireless connection with my router. | | Also, here are more details: | | WEP on, encryption is 128 bits, BSD 6.0, PCI card is Cisco Aironet 350, | AMD athalon. Is this mini-PCI. If so down-rev the firmware. I got it working better with newer version of mini-PCI but ran into problem in which checking on status while sending data could wedge the card. Doing a kldunload/kldload fixes it but my reset attempts methods didn't :-( I also have the HW MIC support added but not the SW bits. I been derailed on too many other FreeBSD problems to make much progress. I have lots of things that need polish before they can be commited but don't have the time to do that :-( The biggest thing is an OpenIPMI compatable IPMI driver so ipmitool etc. can talk via the motherboard interface. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hey everyone
Andre Oppermann writes: | Jack Vogel wrote: | | Dear Jack, | | > I wanted to introduce myself to the list. I am now the primary contact | > at Intel for our drivers. There was some earlier email I saw in the archive | > about 82571/2 support, and I want to confirm that that code is coming. | | for a too long time Intel has abandoned their direct involvement in | the FreeBSD 'em' driver. And you have two people with direct commit | rights to the FreeBSD CVS tree. | | In the meantime we have taken the driver maintainance into our own | hands, have rewritten parts of it and got a lot more conforming code. | Not to mention that we were able to increase the performance significantly | too. We have fixed many show-stopper bugs which were wedging the hardware | as well. ... and introduced a machine lock-up bug :-( Jack has a fix for it. So it works both ways. | Before you continue development on your own FreeBSD driver please have a | very close look the version we have in our CVS tree. You may benefit from | taking that as base and continue development from it instead of your own | code. The CVS commit messages explain in much detail which problems we | found and how we solved them. | http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/em/if_em.c | | Intel would help us a lot if you would release the Erratas to your 'em' | chip famility. I think you might be a little harsh. I think I understand where both sides are coming from. I know when I was at Vernier and Prafulla was maintaining things that he didn't take some cool changes that Sam Leffler did for us with jumbo packets so IPsec with HW crypto screamed. Since this was going to be hard for Intel to make backward compatible they didn't take the jumbo packet stuff with #ifdef mess. Now yes, Intel has been somewhat slow getting the latest greatest stuff into FreeBSD recently but in general it's a lot better then Broadcom. So we need to leverage their access to non-public documents and that Intel pays them to work on this stuff but not just for FreeBSD. I totally understand how things can get slowed down. At the company I work for that pays me to do FreeBSD work I have several FreeBSD fixes, patches and new stuff. Some is locked under NDA and can only be shared via those that have mutual NDA's. Other stuff is in a form good enough for our customers but not ready for FreeBSD. Also since our product is based on FreeBSD 4.X taking our fixes for that to FreeBSD -current -> 6 -> 5 -> 4 is a huge pain and the hacks that are okay to fix our problem and move on it not good enough for FreeBSD. Since I have to fight the next fire, I don't have the cycles to get to the point to commit. I wouldn't mind sharing the open code with people to help out (read people that can code things and not just test). Since it isn't complete I can't commit it to CVS. I guess I could use Perforce but that is yet another thing to deal with. Now I would have our work trees, Perforce and CVS repo's that add's even more work. It's almost getting to the point it is to hard to do work on FreeBSD! Now I'm sure we will be moving to FreeBSD 6 and things will get better for me. It was a good thing we didn't move to FreeBSD 5 or I'd have even more hassle. | > I hope to be adding some new feature support as well. I have been | > eyeing TSO which is going to need stack changes, if anyone out there | > has been working or just thinking about that get in touch with me about it. | | We have already looked into TSO a bit and so far the result is inconclusive. | We may not want to make any large changes to the TCP code to faciliate any | particular TSO architecture. To make the case in favor of supporting TSO | it has to be shown that is provides real-world benefits and extensive | benchmark results have to be provided. Any changes to our TCP code to | support TSO must be well designed and be generic supporting other vendors | TSO as well. However I must say that a really compelling has to be made | for TSO to justify the changes and the associated long term code maintainance | hurdles with it. | | Please have a look at this paper discussing TSO among other things: | | http://people.freebsd.org/~andre/Optimizing%20the%20FreeBSD%20IP%20and%20TCP%20Stack.pdf Yes, I wonder the value of TSO and even HW crypto IPsec off-loading with IP stacks built in. Our network stack is very powerful and has lots of hooks into it that allow lots of things to be inter-mixed. I doubt HW offloading will permit the level of integration we have now. I've told various vendors that pitch this stuff no thanks. Usually most of it isn't open. | > In any case, I am kept quite busy but I will make every effort to be here | > and be as responsive as i can. | | Please get in contact with Gelb Smirnoff <[EMAIL PROTECTED]>, Pyun YongHyeon | <[EMAIL PROTECTED]> and Scott Long <[EMAIL PROTECTED]>. Those folks have | assumed maintainership of the 'em' driver and contributed many important fixes | and
Re: bge BCM5721/BCM5750 fixes to work with IPMI
Doug Ambrisko writes:
| Here are some first pass patches to make the bge driver not break IPMI.
| This was tested on a Dell PE850:
| bge0: mem
0xfe6f-0xfe6f irq 16 at device 0.0 on pci4
| miibus1: on bge0
| brgphy0: on miibus1
| brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX,
1000baseTX-FDX, auto
|
| It shouldn't break other bge cards and it might work with other Broadcom
| IPMI capable chips (they seem to have different usages). Please let me know
| how this goes.
|
| I gleaned this info. from the Linux drivers. YMMV.
I have an updated patch for -current as of today and fixed some issues.
It's getting closer to something that is final. The only issues are
"sharing" access to the PHY since both the device driver and the ASF/IPMI
internal firmware stack also talks to the PHY. If this is not done
carefully it can take the chip off the net. It can also return bogus
values randomly due to contention. Broadcom's Linux driver just skips
talking to it at times and returns the expected values. I've tried my
best at dealing with this. I need to get some doc's that might explain
how we can share talking to the PHY rather then guessing. This now works
after PXE and non PXE boots and with chips not running the internal
ASF/IPMI stack.
Let me know if it causes problems or works.
Doug A.
Index: if_bge.c
===
RCS file: /usr/local/cvsroot/freebsd/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.113
diff -u -p -r1.113 if_bge.c
--- if_bge.c13 Jan 2006 08:59:40 - 1.113
+++ if_bge.c13 Jan 2006 21:52:53 -
@@ -271,7 +271,12 @@ static void bge_poll_locked(struct ifne
int count);
#endif
-static void bge_reset (struct bge_softc *);
+#define BGE_RESET_START 1
+#define BGE_RESET_STOP 2
+static void bge_sig_post_reset(struct bge_softc *, int);
+static void bge_sig_legacy(struct bge_softc *, int);
+static void bge_sig_pre_reset(struct bge_softc *, int);
+static int bge_reset (struct bge_softc *);
static void bge_link_upd (struct bge_softc *);
static device_method_t bge_methods[] = {
@@ -579,6 +584,15 @@ bge_miibus_readreg(dev, phy, reg)
if (phy != 1)
return(0);
+ if (sc->bge_asf_mode & ASF_STACKUP) {
+ BGE_CLRBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP);
+ for (i = 0; i < BGE_TIMEOUT; i++) {
+ val = CSR_READ_4(sc, BGE_MI_COMM);
+ if (!(val & BGE_MICOMM_BUSY))
+ break;
+ }
+ }
+
/* Reading with autopolling on may trigger PCI errors */
autopoll = CSR_READ_4(sc, BGE_MI_MODE);
if (autopoll & BGE_MIMODE_AUTOPOLL) {
@@ -609,6 +623,26 @@ done:
DELAY(40);
}
+ if (sc->bge_asf_mode & ASF_STACKUP)
+ BGE_SETBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP);
+if (sc->bge_asf_mode & ASF_STACKUP
+ && pci_get_device(sc->bge_dev) == BCOM_DEVICEID_BCM5721) {
+ switch (reg) {
+case MII_PHYIDR1:
+val = 0x0020;
+ break;
+case MII_PHYIDR2:
+val = 0x6180;
+ break;
+case MII_BMSR:
+ val |= BMSR_100TXFDX | BMSR_100TXHDX | BMSR_10TFDX
+ | BMSR_10THDX | BMSR_EXTSTAT
+ | BMSR_MFPS
+ | BMSR_ANEG | BMSR_EXTCAP;
+ break;
+ }
+}
+
if (val & BGE_MICOMM_READFAIL)
return(0);
@@ -626,6 +660,15 @@ bge_miibus_writereg(dev, phy, reg, val)
sc = device_get_softc(dev);
+ if (sc->bge_asf_mode & ASF_STACKUP) {
+ BGE_CLRBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP);
+ for (i = 0; i < BGE_TIMEOUT; i++) {
+ val = CSR_READ_4(sc, BGE_MI_COMM);
+ if (!(val & BGE_MICOMM_BUSY))
+ break;
+ }
+ }
+
/* Reading with autopolling on may trigger PCI errors */
autopoll = CSR_READ_4(sc, BGE_MI_MODE);
if (autopoll & BGE_MIMODE_AUTOPOLL) {
@@ -646,6 +689,9 @@ bge_miibus_writereg(dev, phy, reg, val)
DELAY(40);
}
+ if (sc->bge_asf_mode & ASF_STACKUP)
+ BGE_SETBIT(sc, BGE_MODE_CTL, BGE_MODECTL_STACKUP);
+
if (i == BGE_TIMEOUT) {
if_printf(sc->bge_ifp, "PHY read timed out\n");
return(0);
@@ -660,10 +706,21 @@ bge_miibus_statchg(dev)
{
struct bge_softc *sc;
struct mii_data *mii;
+ int i, val;
sc
Re: em driver + VLAN's
Dave Raven writes: | FreeBSD 4.9 - char em_driver_version[] = "1.7.16"; | | I've tried multiple bridge configurations - from bridging just em0,em1 to | bridging two vlan's attached to each card. Unfortunately I don't have access | to the box at the moment - if its still necessary I will fetch the | information tomorrow (ifconfig etc) | | To sum up its something like the following | net.inet.ether.bridge_config=em0,em1 | net.inet.ether.bridge=1 | | Or vlan0,vlan1 with: | ifconfig vlan0 create | ifconfig vlan1 create | ifconfig vlan0 vlan 100 vlandev em0 | ifconfig vlan1 vlan 100 vlandev em1 | | | If I change to using fxp it immediately works.. I think you will find you are bridging in promiscous mode and the HW VLAN stuff isn't there. You should try to bridge the vlan devices or disable the VLAN HW (driver hack). It works with the fxp0 since you are using SW VLAN so the HW part isn't grabing it. I've done the driver hack for some things I needed to do. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em driver + VLAN's
Sten Spans writes: | On Wed, 18 Jan 2006, Doug Ambrisko wrote: | > Dave Raven writes: | > | FreeBSD 4.9 - char em_driver_version[] = "1.7.16"; | > | | > | I've tried multiple bridge configurations - from bridging just em0,em1 to | > | bridging two vlan's attached to each card. Unfortunately I don't have access | > | to the box at the moment - if its still necessary I will fetch the | > | information tomorrow (ifconfig etc) | > | | > | To sum up its something like the following | > | net.inet.ether.bridge_config=em0,em1 | > | net.inet.ether.bridge=1 | > | | > | Or vlan0,vlan1 with: | > | ifconfig vlan0 create | > | ifconfig vlan1 create | > | ifconfig vlan0 vlan 100 vlandev em0 | > | ifconfig vlan1 vlan 100 vlandev em1 | > | | > | | > | If I change to using fxp it immediately works.. | > | > I think you will find you are bridging in promiscous mode and the | > HW VLAN stuff isn't there. You should try to bridge the vlan devices | > or disable the VLAN HW (driver hack). It works with the fxp0 since you | > are using SW VLAN so the HW part isn't grabing it. I've done the driver | > hack for some things I needed to do. | | what about vlanhwtag (ifconfig) ? | according to the em manpage it is disabled by default | so this setup should work. I'm not sure ... things have changed over time. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Default gateway - wrong interface. !
Gleb Smirnoff writes:
| On Sun, Feb 19, 2006 at 03:14:35PM +, Josef Karthauser wrote:
| J> I'm guessing that this is a bug (or feature!).
|
| This is not a bug, nor a feature. This is a feature, that hasn't
| been implemented to the end.
|
| Historically, the routes in kernel were static. And they are static
| now. Historically, BSD won't permit you to install same IP addresses,
| or even addresses in the same subnet, on different interfaces. Now,
| FreeBSD permits addresses in the same subnet. But route entries are
| still static, and aren't reconfigring when an interface changes its
| flags.
|
| J> I've got a machine with a wlan interface (iwi0), with an ipv4 network
| J> address and a default gateway. I also have an ethernet card in the same
| J> machine (em0) with the same IP address. The idea is that I can bring
| J> the wireless down, and the wired interface up to get fast transfers when
| J> approriate, and be wireless the rest of the time.
| J>
| J> That works fine, apart from the default gateway:
| J>
| J> # ifconfig iwi0 down
| J> # ifconfig em0 up
| J> # arp -ad
| J> # netstat -rn
| J> Internet:
| J> DestinationGatewayFlagsRefs Use Netif
| J> Expire
| J> default87.74.4.33 UGS 0 123 iwi0
| J> 87.74.4.32/27 link#3 UC 00em0
| J> 87.74.4.33 00:90:d0:02:3f:16 UHLW21em0
| J> 87.74.4.34 00:d0:b7:88:c8:20 UHLW1 1191414em0
| J> 127.0.0.1 127.0.0.1 UH 02lo0
| J>
| J> Notice, the local subnet is off the em0, but the default route is still
| J> wired off the iwi0.
| J>
| J> # route delete default
| J> # route add default 87.74.4.33
| J> # netstat -rn
| J> Internet:
| J> DestinationGatewayFlagsRefs Use Netif
| J> Expire
| J> default87.74.4.33 UGS 0 123 iwi0
| J> 87.74.4.32/27 link#3 UC 00em0
| J> 87.74.4.33 00:90:d0:02:3f:16 UHLW21em0
| J> 87.74.4.34 00:d0:b7:88:c8:20 UHLW1 1191414em0
| J> 127.0.0.1 127.0.0.1 UH 02lo0
| J>
| J> The default route is _still_ off iwi0; but should be off em0.
| J>
| J> There's obviously something dumb doing on here. Why does the default
| J> route have to be nailed to an interface? It's clear that 87.74.4.33 is
| J> available from em0 as far as the routing table is concerned.
FWIW, we have a patch here for 4.X that deals with this:
Index: sys/net/if.c
===
RCS file: /usr/local/cvsroot/freebsd/src/sys/net/if.c,v
retrieving revision 1.85.2.25
diff -u -p -r1.85.2.25 if.c
--- sys/net/if.c28 Nov 2003 15:09:03 - 1.85.2.25
+++ sys/net/if.c14 Oct 2004 03:49:08 -
@@ -553,6 +553,7 @@ ifa_ifwithaddr(addr)
#defineequal(a1, a2) \
(bcmp((caddr_t)(a1), (caddr_t)(a2), ((struct sockaddr *)(a1))->sa_len) == 0)
TAILQ_FOREACH(ifp, &ifnet, if_link)
+ if (ifp->if_flags & IFF_UP)
TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) {
if (ifa->ifa_addr->sa_family != addr->sa_family)
continue;
@@ -578,7 +579,7 @@ ifa_ifwithdstaddr(addr)
register struct ifaddr *ifa;
TAILQ_FOREACH(ifp, &ifnet, if_link)
- if (ifp->if_flags & IFF_POINTOPOINT)
+ if (ifp->if_flags & IFF_POINTOPOINT && ifp->if_flags & IFF_UP)
TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) {
if (ifa->ifa_addr->sa_family != addr->sa_family)
continue;
@@ -617,6 +618,7 @@ ifa_ifwithnet(addr)
* addresses in this address family.
*/
TAILQ_FOREACH(ifp, &ifnet, if_link) {
+if (ifp->if_flags & IFF_UP)
TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) {
register char *cp, *cp2, *cp3;
I had to fix a couple of these since we up/down NIC's like you say.
We also have a local patch to make some NIC to just turn off/on the
RX & TX stuff during a down/up so that the NIC doesn't re-initialize.
I'm not sure how well it fits in with -current and that future network
changes. If the network guys would like this added I could do it.
Doug A.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPMI During Boot
Julian Elischer writes: | Working with intel (TM) motherboards using the Intel Gb chips, | and talking to the intel reps last year (for my previous employer) I was | led to believe that | these chips supported IPMI by giving the BMC a back door into the same | NIC that the | OS was using. | (using an I2c (SMB) interface) | On the machines I used, I am pretty sure the bios gave the same MAC | address to the BMC | side of things as the OS side of theings by default, and we had is set | up so that we used the | same IP address also. ... and at your current employer that is not required nor setup that way, albeit, with different HW (Intel chip on Dell server). ambrisko 5] ipmitool lan print 1 Set in Progress : 0x00 Auth Type : 0x17 Auth Type Enable: callback=0x06 user=0x06 operator=0x06 admin=0x06 oem=0x06 IP Address Source : 0x01 IP Address : 1.1.1.1 Subnet Mask : 255.255.255.0 MAC Address : 00:11:43:31:56:61 SNMP Community String : public IP Header : TTL=0x40 flags=0x40 precedence=0x00 TOS=0x10 Default Gateway IP : 1.1.1.254 Default Gateway MAC : 00:00:00:00:00:00 Backup Gateway IP : 0.0.0.0 Backup Gateway MAC : 00:00:00:00:00:00 ambrisko 6] ifconfig -a | grep 00:11:43:31:56 ether 00:11:43:31:56:5f ether 00:11:43:31:56:60 ambrisko 7] ifconfig em0 em0: flags=8843 mtu 1500 options=3 inet 192.168.98.87 netmask 0xff00 broadcast 192.168.98.255 ether 00:11:43:31:56:5f media: Ethernet autoselect (1000baseTX ) status: active ambrisko 11] pciconf -l | grep em0 [EMAIL PROTECTED]:7:0: class=0x02 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 ambrisko 12] Which can make it interesting since we can query itself over the network via a router to itself: ambrisko 17] ipmitool -I lan -H 1.1.1.1 sel SEL Information Version : 51 Entries : 64 Free Space : 7168 Last Add Time: 03/02/2006 19:15:25 Last Del Time: 10/07/2005 16:18:14 Overflow : false Delete cmd : unsupported Parial add cmd : unsupported Reserve cmd : supported Get Alloc Info : unsupported ambrisko 18] Note that we have a hacked up/down. You might try to "ifconfig down" the interface and see if that breaks things and it "up" brings it back to life. With the Broadcom NIC we have to be careful to keep the window short when the NIC's IPMI/ASF stack is not up. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPMI and bge (again)
Oleg Bulyzhin writes: | On Tue, Mar 28, 2006 at 11:24:06AM -0600, Stephen P. Cravey wrote: | > Does anyone have chip documentation on the broadcom BGE chips? I'm having an ongoing issue with IPMI that I'd really like to get resolved. The issue seems to be that during the driver start sequence, a flag is getting set in the chip that's disabling the IPMI passthrough that I need in order for data destined for a second mac address on the interface to recieve packets. Or, a flag that this process needs isn't getting set. Not sure which, but I could really use some help here. | > | > Or should I ask the frequent committers to the driver directly? | > | > Thank you. | > | > PR: | > kern/79143 | > kern/88741 | > ___ | | Could you please test attached patch (RELENG_6 version)? It's slightly | modified version of Doug Ambrisko | ([EMAIL PROTECTED]) patch (original version didnt work for me: | bcm5721 @ hp proliant dl145g2 server). I don't see it attached. I'd like to see your changes and I'd like know of your plans about getting it in. Thanks, Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPMI and bge (again)
Oleg Bulyzhin writes: | On Tue, Mar 28, 2006 at 12:38:42PM -0800, Doug Ambrisko wrote: | | > I don't see it attached. I'd like to see your changes and I'd like know | > of your plans about getting it in. | | I didnt test it under load yet (server i've used moved to production so | i have limited testing capabilites atm). | Issue to be fixed: we should not touch phy in bge_stop having asf enabled. | I think your patch is worth commiting to HEAD asap but shouldnt be MFCed | prior 6.1R. What do you think? I'll merge your changes in and make sure it has the heart beat change then commit it to -current. Yes, I agree this is not a candidate for 6.1. If it doesn't cause troubles then it should make it into 6.2. Thanks, Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPMI and bge (again)
Oleg Bulyzhin writes: | On Tue, Mar 28, 2006 at 02:51:48PM -0600, Stephen P. Cravey wrote: | > I don't see the patch either. Does it require pxe booting like Dougs? | > I actually have pulled a system out of service specifically to use for | > testing BGE patches, so it's fairly easy for me to test new versions. | > I eagerly await a copy of your patch. | | PXE boot is not required (Doug's version he gave me didnt require it either). | Actually, it's almost identical to original version - only thing has changed: | asf enable code was move past bge_reset call. He was referring to my very first cut I posted which did :-( I had only tested with a netboot version. I had since fixed and posted an update that didn't require it. FWIW, the version I sent you had the ASF heart beat added and another thing fixed. So this version should be even better. I'm about ready to boot with your update. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPMI and bge (again)
Hi guys,
Could you try this latest version. It incorporates Oleg
change sort-of. It was a good hint. The issue is that
we can't move the detection after the "reset" dance. Since
it needs to know if ASF is active. What we can do is just
do the bge_reset, look for ASF and then do the dance. This
works really well and I makes the PHY probe work without the
one remaining hack that I had left and I was able to get rid
of a couple more hacks.
This applies to RELENG_6.
Please let me know how this works. I'd like to commit
this. Please pay attention to if IPMI works before the
NIC is UP/or has an IP and then when it is ifconfig down
then up again. The PHY should be detected at brgphy
and not the generic one. It should also have all of the
proper speeds. It should work with and without PXE boot.
Finally non-IPMI ones should work.
So far it works on the variants I have.
Thanks,
Doug A.
Index: if_bge.c
===
RCS file: /usr/local/cvsroot/freebsd/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.91.2.13
diff -u -p -r1.91.2.13 if_bge.c
--- if_bge.c4 Mar 2006 09:34:48 - 1.91.2.13
+++ if_bge.c30 Mar 2006 00:32:48 -
@@ -209,6 +209,7 @@ static void bge_dma_free(struct bge_sof
static void bge_txeof (struct bge_softc *);
static void bge_rxeof (struct bge_softc *);
+static void bge_asf_driver_up (struct bge_softc *);
static void bge_tick_locked(struct bge_softc *);
static void bge_tick (void *);
static void bge_stats_update (struct bge_softc *);
@@ -271,7 +272,12 @@ static void bge_poll_locked(struct ifne
int count);
#endif
-static void bge_reset (struct bge_softc *);
+#define BGE_RESET_START 1
+#define BGE_RESET_STOP 2
+static void bge_sig_post_reset(struct bge_softc *, int);
+static void bge_sig_legacy(struct bge_softc *, int);
+static void bge_sig_pre_reset(struct bge_softc *, int);
+static int bge_reset (struct bge_softc *);
static void bge_link_upd (struct bge_softc *);
static device_method_t bge_methods[] = {
@@ -660,10 +666,10 @@ bge_miibus_statchg(dev)
{
struct bge_softc *sc;
struct mii_data *mii;
-
sc = device_get_softc(dev);
mii = device_get_softc(sc->bge_miibus);
+
BGE_CLRBIT(sc, BGE_MAC_MODE, BGE_MACMODE_PORTMODE);
if (IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_T) {
BGE_SETBIT(sc, BGE_MAC_MODE, BGE_PORTMODE_GMII);
@@ -1007,6 +1013,80 @@ bge_setmulti(sc)
return;
}
+static void
+bge_sig_pre_reset(sc, type)
+ struct bge_softc *sc;
+ int type;
+{
+ bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER);
+
+ if (sc->bge_asf_mode & ASF_NEW_HANDSHAKE) {
+ switch (type) {
+ case BGE_RESET_START:
+ bge_writemem_ind(sc, BGE_SDI_STATUS, 0x1); /* START */
+ break;
+ case BGE_RESET_STOP:
+ bge_writemem_ind(sc, BGE_SDI_STATUS, 0x2); /* UNLOAD */
+ break;
+ }
+ }
+}
+
+static void
+bge_sig_post_reset(sc, type)
+ struct bge_softc *sc;
+ int type;
+{
+ if (sc->bge_asf_mode & ASF_NEW_HANDSHAKE) {
+ switch (type) {
+ case BGE_RESET_START:
+ bge_writemem_ind(sc, BGE_SDI_STATUS, 0x8001);
+ /* START DONE */
+ break;
+ case BGE_RESET_STOP:
+ bge_writemem_ind(sc, BGE_SDI_STATUS, 0x8002);
+ break;
+ }
+ }
+}
+
+static void
+bge_sig_legacy(sc, type)
+ struct bge_softc *sc;
+ int type;
+{
+ if (sc->bge_asf_mode) {
+ switch (type) {
+ case BGE_RESET_START:
+ bge_writemem_ind(sc, BGE_SDI_STATUS, 0x1); /* START */
+ break;
+ case BGE_RESET_STOP:
+ bge_writemem_ind(sc, BGE_SDI_STATUS, 0x2); /* UNLOAD */
+ break;
+ }
+ }
+}
+
+void bge_stop_fw(struct bge_softc *);
+void
+bge_stop_fw(sc)
+ struct bge_softc *sc;
+{
+ int i;
+
+ if (sc->bge_asf_mode) {
+ bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM_FW, BGE_FW_PAUSE);
+ CSR_WRITE_4(sc, BGE_CPU_EVENT,
+ CSR_READ_4(sc, BGE_CPU_EVENT) != (1 << 14));
+
+ for (i = 0; i < 100; i++ ) {
+ if (!(CSR_READ_4(sc, BGE_CPU_EVENT) & (1 << 14)))
+ break;
+ DELAY(10);
+ }
+ }
+}
+
/*
* Do endian, PCI and DMA initialization. Also check the on-board ROM
* self-test results.
@@ -1018,7 +1098,7 @@ bge_chipinit(sc)
int i;
u_int32_t dma_rw_ctl;
-
Re: Marvell 88E8053 lan controller support
Brad writes: | On Tue, Apr 25, 2006 at 11:36:17AM -0700, Paul Saab wrote: | > Brad wrote: | > > | > >Source exists for newer Broadcom Gig chips (575x and derivatives) yet | > >there is no documentation available for that either. | > | > Documentation does exist, just not publically. | | Ya, just as documentation does exist for Yukon II but it is also | not available publically. As goes for numerous other MAC/PHY/SCSI/RAID | chipsets. If it's not in the hands of the right people then it does not | do us any good. I think you missed Paul's point. Documentation has been made available to people in the FreeBSD project from Broadcom. If I wasn't so busy trying to make things work from some other unfriendly companies I could help with some more Broadcom issues. Recently, they just gave us a driver. So "right" may apply to people that have time. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPMI and bge (again)
Robert Wojciechowski writes: | > Could you try this latest version. It incorporates Oleg | > change sort-of. It was a good hint. The issue is that | > we can't move the detection after the "reset" dance. Since | > it needs to know if ASF is active. What we can do is just | > do the bge_reset, look for ASF and then do the dance. This | > works really well and I makes the PHY probe work without the | > one remaining hack that I had left and I was able to get rid | > of a couple more hacks. | > | > This applies to RELENG_6. | > | > Please let me know how this works. I'd like to commit | > this. Please pay attention to if IPMI works before the | > NIC is UP/or has an IP and then when it is ifconfig down | > then up again. The PHY should be detected at brgphy | > and not the generic one. It should also have all of the | > proper speeds. It should work with and without PXE boot. | > Finally non-IPMI ones should work. | > | > So far it works on the variants I have. | | Doug, | | I tried your patch (as well as one from you on 1/13/2006) on FreeBSD | 6.1-RC2 but experienced hard lockups. It happens during startup right | after setting the hostname, right before it would normally bring up the | interface I believe. Could you try: http://www.ambrisko.com/doug/bge_ipmi_2.patch | This is on four different servers, all Supermicro motherboards (H8DAR | and H8DAE) based on the Broadcom BCM5704 chip. | | Here is the pciconf -lv: | | [EMAIL PROTECTED]:3:0: class=0x02 card=0x164815d9 chip=0x164814e4 rev=0x10 | hdr=0x00 | vendor = 'Broadcom Corporation' | device = 'BCM5704 NetXtreme Dual Gigabit Adapter' | class= network | subclass = ethernet | [EMAIL PROTECTED]:3:1: class=0x02 card=0x164815d9 chip=0x164814e4 rev=0x10 | hdr=0x00 | vendor = 'Broadcom Corporation' | device = 'BCM5704 NetXtreme Dual Gigabit Adapter' | class= network | subclass = Ethernet | | Any ideas? If you need any more information or have other patches I can | test for you, let me know! Try this version. If this has trouble we can try to add some debug stuff to it. Thanks, Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPMI and bge (again)
Oleg Bulyzhin writes: | On Wed, May 03, 2006 at 08:54:09PM -0700, Doug Ambrisko wrote: | > Robert Wojciechowski writes: | > | > Could you try this latest version. It incorporates Oleg | > | > change sort-of. It was a good hint. The issue is that | > | > we can't move the detection after the "reset" dance. Since | > | > it needs to know if ASF is active. What we can do is just | > | > do the bge_reset, look for ASF and then do the dance. This | > | > works really well and I makes the PHY probe work without the | > | > one remaining hack that I had left and I was able to get rid | > | > of a couple more hacks. | > | > | > | > This applies to RELENG_6. | > | > | > | > Please let me know how this works. I'd like to commit | > | > this. Please pay attention to if IPMI works before the | > | > NIC is UP/or has an IP and then when it is ifconfig down | > | > then up again. The PHY should be detected at brgphy | > | > and not the generic one. It should also have all of the | > | > proper speeds. It should work with and without PXE boot. | > | > Finally non-IPMI ones should work. | > | > | > | > So far it works on the variants I have. | > | | > | Doug, | > | | > | I tried your patch (as well as one from you on 1/13/2006) on FreeBSD | > | 6.1-RC2 but experienced hard lockups. It happens during startup right | > | after setting the hostname, right before it would normally bring up the | > | interface I believe. | > | > Could you try: | > http://www.ambrisko.com/doug/bge_ipmi_2.patch | > | > | This is on four different servers, all Supermicro motherboards (H8DAR | > | and H8DAE) based on the Broadcom BCM5704 chip. | > | | > | Here is the pciconf -lv: | > | | > | [EMAIL PROTECTED]:3:0: class=0x02 card=0x164815d9 chip=0x164814e4 rev=0x10 | > | hdr=0x00 | > | vendor = 'Broadcom Corporation' | > | device = 'BCM5704 NetXtreme Dual Gigabit Adapter' | > | class= network | > | subclass = ethernet | > | [EMAIL PROTECTED]:3:1: class=0x02 card=0x164815d9 chip=0x164814e4 rev=0x10 | > | hdr=0x00 | > | vendor = 'Broadcom Corporation' | > | device = 'BCM5704 NetXtreme Dual Gigabit Adapter' | > | class= network | > | subclass = Ethernet | > | | > | Any ideas? If you need any more information or have other patches I can | > | test for you, let me know! | > | > Try this version. If this has trouble we can try to add some debug | > stuff to it. | > | > Thanks, | > | > Doug A. | | I've tested your new patch on hp proliant dl145g2 server with bcm5721 on board | chips: | bge1: mem 0xca10-0xca10 irq 19 at device 0.0 on pci3 | | It does work but i've found some problems: | | minor ones: | 1) IPMI stop working for a few seconds while ifconfig bge1 up/down or driver | initialization (perhaps this happens when bge_reset() is called) This is expected and happens under Linux etc. If it didn't happen then we wouldn't need driver support for it! | 2) IPMI interface (bound to brgphy1) is unreachable from bge1 itself. I guess | it's due to simplex nature of bge. I'm not sure this can be fixed. Correct, if you have a routable connect then you can talk back to your self. | major one: | Driver is unable to detect link loss. Problematic code is in bge_tick_locked: | | /* Don't mess with the PHY in IPMI/ASF mode */ | if (!((sc->bge_asf_mode & ASF_STACKUP) && (sc->bge_link))) | mii_tick(mii); | | what purpose of this check? mii_tick() call is necessary for updating phy's | link status. In IPMI enabled we can't read the PHY much since the ASF firmware is also reading it. This can result in lock ups of the firmware :-( Both the driver and the ASF part stops working. So I only allow reads until we have link. I used to be able to detect if IPMI was enabled on the chip and then only prevent the poll in that case. Since your chip needed the reset first we lose that state info. So now I have to assume it on if the chip is capable :-( Linux goes a step further and never reads from the PHY. I've got it so I can read okay during initialization. If I could talk to chip reliably to read the asf stack up state then things would be better on machines that have multiple of these NIC's. Intel doesn't have as much issues. The new bce seems better, however, in DDB is seems IPMI stops working on the bce driver. The doc's don't really go into great detail and we found one chip (5704C) that barf's on: bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER); in bge_sig_pre_reset. I'm thinking we might want to try a sysctl to enable IPMI or only do this stuff for IPMI capable chips. Slowly things are getting better. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vlan/bridge problems..
Evren Yurtesen writes: | I tried to bridge vlan with ethernet but I am having troubles. | | net.link.ether.bridge_cfg: fxp0:2,fxp3:2,fxp2:3,vlan0:3 | net.link.ether.bridge: 1 | net.link.ether.bridge_ipfw: 0 | net.link.ether.bridge_ipf: 0 | net.link.ether.bridge_ipfw_drop: 0 | net.link.ether.bridge_ipfw_collisions: 0 | | fxp0 - fxp3 bridge works fine | vlan0 is attached to fxp3 (trunk) | | vlan0 - fxp2 bridge doesnt work! I can ping IP of fxp2 but not to any | host connected to fxp2. | | Can this be because I am using fxp3 as a normal interface + a vlan trunk | at the same time? It wouldn't work for me since the if_vlan device call the device driver's output mechanism direct and the SW input path would ignore handling of VLAN packets ... or atleast this used to be issues. My machine's that I needed this for are patched locally to make it work. I don't know the current state of this. It gets to be a bit of a mess re-injection the packet into the stack on output with loops etc. The ordering of post netgraph/bridge has some issues. It probably should be tagged and use that to prevent loops. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vlan/bridge problems..
Julian Elischer writes: | Evren Yurtesen wrote: | > Doug Ambrisko wrote: | > | >> Evren Yurtesen writes: | >> | I tried to bridge vlan with ethernet but I am having troubles. | >> | | net.link.ether.bridge_cfg: fxp0:2,fxp3:2,fxp2:3,vlan0:3 | >> | net.link.ether.bridge: 1 | >> | net.link.ether.bridge_ipfw: 0 | >> | net.link.ether.bridge_ipf: 0 | >> | net.link.ether.bridge_ipfw_drop: 0 | >> | net.link.ether.bridge_ipfw_collisions: 0 | >> | | fxp0 - fxp3 bridge works fine | >> | vlan0 is attached to fxp3 (trunk) | >> | | vlan0 - fxp2 bridge doesnt work! I can ping IP of fxp2 but not to | >> any | host connected to fxp2. | >> | | Can this be because I am using fxp3 as a normal interface + a | >> vlan trunk | at the same time? | >> | >> It wouldn't work for me since the if_vlan device call the device | >> driver's output mechanism direct and the SW input path would ignore | >> handling of VLAN | >> packets ... or atleast this used to be issues. My machine's that I | >> needed | >> this for are patched locally to make it work. | >> | >> I don't know the current state of this. It gets to be a bit of | >> a mess re-injection the packet into the stack on output with loops etc. | >> The ordering of post netgraph/bridge has some issues. It probably | >> should be tagged and use that to prevent loops. | > | > Well, I think vlans do not bridge on 4.x | | that may or may not be true.. I think I have seen it working.. | I think netgraph bridging should work. Only if doing netgraph vlan. Not if_vlan. | it may depend of whether you are doing hardware vlan tagging. I disable HW vlan support. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
patch to not route on down interfaces
Hi guys,
We "hack" a feature to have 2 NIC's configured with the same IP and
netmask. We down one and up the other to bounce between then. We
also set the MAC's to be the same. This fixes a few routing problems
in which the route would be tied to the down interface and not the
up one :-(
--- ../src/sys/net/if.c Tue Feb 14 19:37:15 2006
+++ ./sys/net/if.c Tue Sep 5 12:21:46 2006
@@ -986,7 +986,9 @@ ifa_ifwithaddr(struct sockaddr *addr)
struct ifaddr *ifa;
IFNET_RLOCK();
- TAILQ_FOREACH(ifp, &ifnet, if_link)
+ TAILQ_FOREACH(ifp, &ifnet, if_link) {
+ if (!ifp->if_flags & IFF_UP)
+ continue;
TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) {
if (ifa->ifa_addr->sa_family != addr->sa_family)
continue;
@@ -999,6 +1001,7 @@ ifa_ifwithaddr(struct sockaddr *addr)
sa_equal(ifa->ifa_broadaddr, addr))
goto done;
}
+ }
ifa = NULL;
done:
IFNET_RUNLOCK();
@@ -1017,6 +1020,8 @@ ifa_ifwithdstaddr(struct sockaddr *addr)
IFNET_RLOCK();
TAILQ_FOREACH(ifp, &ifnet, if_link) {
+ if (!ifp->if_flags & IFF_UP)
+ continue;
if ((ifp->if_flags & IFF_POINTOPOINT) == 0)
continue;
TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) {
@@ -1062,6 +1067,8 @@ ifa_ifwithnet(struct sockaddr *addr)
*/
IFNET_RLOCK();
TAILQ_FOREACH(ifp, &ifnet, if_link) {
+ if (!ifp->if_flags & IFF_UP)
+ continue;
TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) {
char *cp, *cp2, *cp3;
--- ../src/sys/netinet/in.c Tue Jan 31 08:11:37 2006
+++ ./sys/netinet/in.c Tue Sep 5 16:09:00 2006
@@ -870,6 +871,8 @@ in_scrubprefix(target)
}
TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) {
+ if (ia->ia_ifp && !(ia->ia_ifp->if_flags & IFF_UP))
+ continue;
if (rtinitflags(ia))
p = ia->ia_dstaddr.sin_addr;
else {
Thanks,
Doug A.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: patch to not route on down interfaces
Oleg Bulyzhin writes:
| On Thu, Sep 07, 2006 at 11:30:55AM -0700, Doug Ambrisko wrote:
| > Hi guys,
| >
| > We "hack" a feature to have 2 NIC's configured with the same IP and
| > netmask. We down one and up the other to bounce between then. We
| > also set the MAC's to be the same. This fixes a few routing problems
| > in which the route would be tied to the down interface and not the
| > up one :-(
|
| I guess this one is wrong:
| > + if (!ifp->if_flags & IFF_UP)
|
| it would lead to ((!ifp->if_flags) & IFF_UP), whereas it should be:
| (!(ifp->if_flags & IFF_UP))
Fixed it. It seems that with how things are different now versus
4.x we almost never hit the if.c part mostly just the in.c change.
Here is the new one:
--- ../src/sys/net/if.c Tue Feb 14 19:37:15 2006
+++ ./sys/net/if.c Tue Sep 5 12:21:46 2006
@@ -986,7 +986,9 @@ ifa_ifwithaddr(struct sockaddr *addr)
struct ifaddr *ifa;
IFNET_RLOCK();
- TAILQ_FOREACH(ifp, &ifnet, if_link)
+ TAILQ_FOREACH(ifp, &ifnet, if_link) {
+ if (!(ifp->if_flags & IFF_UP))
+ continue;
TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) {
if (ifa->ifa_addr->sa_family != addr->sa_family)
continue;
@@ -999,6 +1001,7 @@ ifa_ifwithaddr(struct sockaddr *addr)
sa_equal(ifa->ifa_broadaddr, addr))
goto done;
}
+ }
ifa = NULL;
done:
IFNET_RUNLOCK();
@@ -1017,6 +1020,8 @@ ifa_ifwithdstaddr(struct sockaddr *addr)
IFNET_RLOCK();
TAILQ_FOREACH(ifp, &ifnet, if_link) {
+ if (!(ifp->if_flags & IFF_UP))
+ continue;
if ((ifp->if_flags & IFF_POINTOPOINT) == 0)
continue;
TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) {
@@ -1062,6 +1067,8 @@ ifa_ifwithnet(struct sockaddr *addr)
*/
IFNET_RLOCK();
TAILQ_FOREACH(ifp, &ifnet, if_link) {
+ if (!(ifp->if_flags & IFF_UP))
+ continue;
TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) {
char *cp, *cp2, *cp3;
--- ../src/sys/netinet/in.c Tue Jan 31 08:11:37 2006
+++ ./sys/netinet/in.c Tue Sep 5 16:09:00 2006
@@ -870,6 +871,8 @@ in_scrubprefix(target)
}
TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) {
+ if (ia->ia_ifp && !(ia->ia_ifp->if_flags & IFF_UP))
+ continue;
if (rtinitflags(ia))
p = ia->ia_dstaddr.sin_addr;
else {
Thanks,
Doug A.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em network issues
John Polstra writes: | On 19-Oct-2006 Scott Long wrote: | > The performance measurements that Andre and I did early this year showed | > that the INTR_FAST handler provided a very large benefit. | | I'm trying to understand why that's the case. Is it because an | INTR_FAST interrupt doesn't have to be masked and unmasked in the | APIC? I can't see any other reason for much of a performance | difference in that driver. With or without INTR_FAST, you've got | the bulk of the work being done in a background thread -- either the | ithread or the taskqueue thread. It's not clear to me that it's any | cheaper to run a task than it is to run an ithread. | | A difference might show up if you had two or more em devices sharing | the same IRQ. Then they'd share one ithread, but would each get their | own taskqueue thread. But sharing an IRQ among multiple gigabit NICs | would be avoided by anyone who cared about performance, so it's not a | very interesting case. Besides, when you first committed this | stuff, INTR_FAST interrupts were not sharable. | | Another change you made in the same commit (if_em.c revision 1.98) | greatly reduced the number of PCI writes made to the RX ring consumer | pointer register. That would yield a significant performance | improvement. Did you see gains from INTR_FAST even without this | independent change? Something that we've fixed locally in atleast one version is: 1) Limit the loop in em_intr to 3 iterations 2) Pass a valid value to em_process_receive_interrupts/em_rxeof a good value like 100 instead of -1. Since this is the count for how many time to iterate over the rx stuff. Seems this got lost in the some change of APIs. 3) In em_process_receive_interrupts/em_rxeof always decrement the count on every run through the loop. If you notice count is an is an int that starts at the passed in value of -1. It then count-- until count==0. Doing -1, -2, -3 takes awhile until the int rolls over to 0. Passing 100 limits it more :-) So this can run 3 * 100 versuses infinite * int roll over assuming we don't skip a count--. Doing these changes made our multiple em based machines a lot happier when slammed with traffic without starving other things that shared interrupts like other em cards (especially in 4.X). Interrupt handler should have limits of how long they should be able to run then let someone else go. We use this in 6.X as well and haven't had any problems with our config's that use this. We haven't tested much without these since we need to fix other issues and this is now a non-issue for us. I haven't pushed this more since I first found issue 1 and the concept was rejected ... my machine hung in the interrupt spin loop :-( If someone wants to examine/play with it more then that's great. These issues (I think they are bugs) have been in there a while. That's my 2 cents. Doug A. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
if_tap.c interaction bug with netgraph??
I've run into this bug since about 4.6-stable of some time. I use netgraph to connect to a tap device in vmnet mode since in vmnet mode it is persistan. In tap mode if comes and goes depending on whether or not I have the device open. Anyways I couldn't get data to come in the vmnet node through netgraph with only the interface up, auto source off and promicious on (ie. bridge mode). This patches fixes it by doing and init to get the interface going. Any objections to this change? If you give the interface an IP then it works okay except you shouldn't have to do that. Thanks, Doug A. Index: net/if_tap.c === RCS file: /home/cvs/freebsd/src/sys/net/if_tap.c,v retrieving revision 1.3.2.3 diff -c -r1.3.2.3 if_tap.c *** net/if_tap.c14 Apr 2002 21:41:48 - 1.3.2.3 --- net/if_tap.c7 Jan 2003 20:02:18 - *** *** 426,431 --- 426,432 return (dummy); case SIOCSIFFLAGS: /* XXX -- just like vmnet does */ + tapifinit(tp); case SIOCADDMULTI: case SIOCDELMULTI: break; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: fxp0: device timeout | SCB already complete.
Palle Girgensohn writes:
| Hi!
|
| When I run network backups, one of our FreeBSD machines (backup client) get
| NIC timeouts and warnings from the scsi driver:
|
| Jun 3 14:50:12 melon /kernel: fxp0: device timeout
| Jun 3 14:50:36 melon /kernel: fxp0: device timeout
| Jun 3 14:51:03 melon /kernel: fxp0: device timeout
| Jun 3 14:51:38 melon /kernel: fxp0: device timeout
| Jun 3 14:52:41 melon /kernel: ahc0: Timedout SCB already complete.
| Interrupts may not be functioning.
| Jun 3 14:53:12 melon /kernel: fxp0: device timeout
|
| Both machines are on a hubbed 100 Mbit/s half duplex network. Looking at
| the traffic with netstat -d 1, I see that as soon as the traffic increases,
| there is a timeout and traffic stops, after with the net is reachable
| again. This goes on and on. It only happens when there is much traffic on
| both NIC and SCSI, it seems (alas when running backups...)
|
| Since there was a second NIC, it tried connecting it to the server using
| that NIC through a switch, on a private network, but then the machine
| nearly crashed, or at least came to a grinding halt. It seems, as soon as I
| pulled the ethernet cable it came back. This happened without any backup
| running...
|
| To me, this sounds like some odd interrupt problem? It is a PCI machine
| with an Intel ?x440 (if memory serves me right) and dual CPUs 400 Mhz,
| running freebsd-4.7p2.
|
| Any ideas where to look, how to debug or what to do?
Try this:
diff -c -r1.1.1.2 -r1.3
*** if_fxp.c28 May 2003 23:39:32 - 1.1.1.2
--- if_fxp.c5 Jun 2003 02:10:23 - 1.3
***
*** 574,579
--- 579,610
}
}
+ if (i == 0x1039 || i == 0x103A) {
+ fxp_read_eeprom(sc, &data, 13, 1);
+ if ((data & 0x0f) == 4) {
+ u_int16_t cksum;
+ int i;
+
+ device_printf(dev,
+ "Fix Tyan bug in EEPROM\n");
+ data = (data & 0xf0) + 0xf;
+ fxp_write_eeprom(sc, &data, 13, 1);
+ device_printf(dev, "New EEPROM ID: 0x%x\n", data);
+ cksum = 0;
+ for (i = 0; i < (1 << sc->eeprom_size) - 1; i++) {
+ fxp_read_eeprom(sc, &data, i, 1);
+ cksum += data;
+ }
+ i = (1 << sc->eeprom_size) - 1;
+ cksum = 0xBABA - cksum;
+ fxp_read_eeprom(sc, &data, i, 1);
+ fxp_write_eeprom(sc, &cksum, i, 1);
+ device_printf(dev,
+ "EEPROM checksum @ 0x%x: 0x%x -> 0x%x\n",
+ i, data, cksum);
+ }
+ }
+
/*
* If we are not a 82557 chip, we can enable extended features.
*/
For kicks. We had to do this on our motherboard. Don't know why. Couldn't
get an answer. I figured this out via a binary search of a good eeprom
contents and bad.
Note you have to boot the kernel twice or power off.
Your mileage may vary. Your machine could blow up etc. This is on a
Tyan 2099GNN board.
Doug A.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Suggesting for fixing VLAN bridging the right way
I'm trying to bridge VLAN traffic to network that doesn't have that VLAN,
something like:
(vlan network) -> fxp0 -> vlan0 <- FreeBSD bridge -> rl0 (no tag)
Both of the networks are the same except one side is tagged the other
has no tag.
It works fine in the "no tag" -> "tag" direction. It fails in the
"tag" -> "no tag" direction since ether_demux we bail out on this
check:
if (!(BDG_ACTIVE(ifp))) {
/*
* Discard packet if upper layers shouldn't see it because it
* was unicast to a different Ethernet address. If the driver
* is working properly, then this situation can only happen
* when the interface is in promiscuous mode.
*/
if ((ifp->if_flags & IFF_PROMISC) != 0
&& (eh->ether_dhost[0] & 1) == 0
&& bcmp(eh->ether_dhost,
IFP2AC(ifp)->ac_enaddr, ETHER_ADDR_LEN) != 0
&& (ifp->if_flags & IFF_PPROMISC) == 0) {
m_freem(m);
return;
}
}
since it doesn't consider VLAN tagged packets coming in the headers
won't match this paradigm so the packets get through out. I did a quick
hack and changed it to:
if (!(BDG_ACTIVE(ifp))) {
/*
* Discard packet if upper layers shouldn't see it because it
* was unicast to a different Ethernet address. If the driver
* is working properly, then this situation can only happen
* when the interface is in promiscuous mode.
*/
if ((ifp->if_flags & IFF_PROMISC) != 0
&& (eh->ether_dhost[0] & 1) == 0
&& bcmp(eh->ether_dhost,
IFP2AC(ifp)->ac_enaddr, ETHER_ADDR_LEN) != 0
&& (ifp->if_flags & IFF_PPROMISC) == 0) {
/*
* Let VLAN packets go to the SW VLAN node needed for
* bridging
*/
if (! (vlan_input_p != NULL
&& ntohs(eh->ether_type) == ETHERTYPE_VLAN )) {
m_freem(m);
return;
}
}
}
That makes it work. I rather doubt this is the right solution.
Suggestions greatly appreciated. This issue is in -current and -stable.
Thanks,
Doug A.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Suggesting for fixing VLAN bridging the right way
Julian Elischer writes:
| how does netgraph bridging do?
I'm actually using netgraph bridging sort-of, kind-of. Since I don't
care about loops and I'm only connecting to interfaces together
I just doing
ngctl connect vlan0: rl0: lower lower
with the setpromisc, setautosrc etc. Luigi's bridging had the
same issue.
This is actually a simple test case. What I'm doing it actually more
complicated for our product VLAN testing. With this hack now my test
stuff works (I do a IP re-map to do a poor man's virtualization of the
network stack ... which by the way I tried out the latest virtual
network stuff. It sort-of worked but ran into some bugs and quirks).
So this is a fundamental bug, in which the packets from the NIC
don't make it to the vlan SW layer and things break. I guess
I didn't explain that part well based on some other questions I got.
You also have to set the NIC in promiscous mode as well. Seems like
if you configure a VLAN and modes those things should get enabled
on the base NIC. Granted it could get funky with HW VLAN support.
It strange since I don't ifconfig the NIC but I always have to do
an 'ifconfig up' to make the VLAN work at all. That's a little
odd.
Also you can see the bug via tcpdumps. You see the packets come in
on the NIC but never make to the vlan iface.
Doug A.
| On Thu, 3 Jul 2003, Doug Ambrisko wrote:
|
| > I'm trying to bridge VLAN traffic to network that doesn't have that VLAN,
| > something like:
| > (vlan network) -> fxp0 -> vlan0 <- FreeBSD bridge -> rl0 (no tag)
| >
| > Both of the networks are the same except one side is tagged the other
| > has no tag.
| >
| > It works fine in the "no tag" -> "tag" direction. It fails in the
| > "tag" -> "no tag" direction since ether_demux we bail out on this
| > check:
| > if (!(BDG_ACTIVE(ifp))) {
| > /*
| > * Discard packet if upper layers shouldn't see it because it
| > * was unicast to a different Ethernet address. If the driver
| > * is working properly, then this situation can only happen
| > * when the interface is in promiscuous mode.
| > */
| > if ((ifp->if_flags & IFF_PROMISC) != 0
| > && (eh->ether_dhost[0] & 1) == 0
| > && bcmp(eh->ether_dhost,
| > IFP2AC(ifp)->ac_enaddr, ETHER_ADDR_LEN) != 0
| > && (ifp->if_flags & IFF_PPROMISC) == 0) {
| > m_freem(m);
| > return;
| > }
| > }
| >
| > since it doesn't consider VLAN tagged packets coming in the headers
| > won't match this paradigm so the packets get through out. I did a quick
| > hack and changed it to:
| > if (!(BDG_ACTIVE(ifp))) {
| > /*
| > * Discard packet if upper layers shouldn't see it because it
| > * was unicast to a different Ethernet address. If the driver
| > * is working properly, then this situation can only happen
| > * when the interface is in promiscuous mode.
| > */
| > if ((ifp->if_flags & IFF_PROMISC) != 0
| > && (eh->ether_dhost[0] & 1) == 0
| > && bcmp(eh->ether_dhost,
| > IFP2AC(ifp)->ac_enaddr, ETHER_ADDR_LEN) != 0
| > && (ifp->if_flags & IFF_PPROMISC) == 0) {
| > /*
| > * Let VLAN packets go to the SW VLAN node needed for
| > * bridging
| > */
| > if (! (vlan_input_p != NULL
| > && ntohs(eh->ether_type) == ETHERTYPE_VLAN )) {
| > m_freem(m);
| > return;
| > }
| > }
| > }
| >
| > That makes it work. I rather doubt this is the right solution.
| >
| > Suggestions greatly appreciated. This issue is in -current and -stable.
| >
| > Thanks,
| >
| > Doug A.
| > ___
| > [EMAIL PROTECTED] mailing list
| > http://lists.freebsd.org/mailman/listinfo/freebsd-net
| > To unsubscribe, send any mail to "[EMAIL PROTECTED]"
| >
|
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about bridging code
[EMAIL PROTECTED] writes: [ Charset ISO-8859-1 unsupported, converting... ] | Hi Luigi, | | Thanks for response, the vmnet/tap stuff sounds like neat stuff. After reading | the description of tap (from the vtun site), the system seems to make a lot of | sense. However, I'm not sure how vmnet comes into play here - what purpose does | it serve, shouldn't I just be able to read from the /dev/tap0 and bridge | between tap0 and fxp0? | | I tried writing a simple program to use tap. Basically, I have the bridge setup | as such | | net.link.ether.bridge_cfg: fxp0:0,tap0:0 tap1:1 bge0:1 | | And I ran this quick test program that I wrote: How about a simpler one echo hello > /dev/vmnet0 cat /dev/vmnet0 | Unfortunately, it doesn't work, it only gets a read event when I make changes | to the tap interface via ifconfig. I guess I don't fully understand how | the /dev/tapN interface works, can you (or anybody who also know) point out | what I'm doing wrong? Thanks again! I use vmnet since it stays persistant across opens and closes. So the above would have issues with tap. For bridging you probably need (for -stable): Index: if_tap.c === RCS file: /cvs/src/sys/net/if_tap.c,v retrieving revision 1.3.2.3 diff -c -r1.3.2.3 if_tap.c *** if_tap.c14 Apr 2002 21:41:48 - 1.3.2.3 --- if_tap.c11 Jul 2003 01:57:28 - *** *** 426,431 --- 426,432 return (dummy); case SIOCSIFFLAGS: /* XXX -- just like vmnet does */ + tapifinit(tp); case SIOCADDMULTI: case SIOCDELMULTI: break; or you lose stuff. I have a user-land packet translator that opens a couple of vmnet devices and then bridge those nodes to the HW I want. It works well. Initially I used tap but since every open and closed created a new iface instance the world started to go bad after a lot of stops and starts of the program. Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question about bridging code
[EMAIL PROTECTED] writes: | > It's just a naming issue, vmnetX is the network-device name of /dev/tapX. | > (the ip-equivalent thing, "tun", has the same name for both the network | > device and the device entry in the filesystem. As a matter of fact the | > latter is totally arbitrary so "tun" perhaps should be called "vmnet"...) | | But when I do a ifconfig, only tapX devices are there, where there is no vmnetX | devices. And when I set up the bridge with vmnetX, the kernel will complain | that the vmnetX devices do not exist. Do I need to perform a makedev on it | first to create the devices? If so, do they have a special major and minor | number that I should assign it to? Yes a different offset of minor number maps into vmnetX: a21p% ls -l /compat/linux/dev/vmnet? crw-r--r-- 1 root wheel 149, 0x00010001 Jul 8 18:34 /compat/linux/dev/vmnet1 crw-r--r-- 1 root wheel 149, 0x00010002 Jul 1 19:20 /compat/linux/dev/vmnet2 crw-r--r-- 1 root wheel 149, 0x00010003 Jul 1 19:20 /compat/linux/dev/vmnet3 crw-r--r-- 1 root wheel 149, 0x00010004 Mar 21 2002 /compat/linux/dev/vmnet4 crw-r--r-- 1 root wheel 149, 0x00010005 May 12 09:26 /compat/linux/dev/vmnet5 crw-r--r-- 1 root wheel 149, 0x00010006 Jun 9 15:45 /compat/linux/dev/vmnet6 crw-r--r-- 1 root wheel 149, 0x00010007 Jun 9 15:45 /compat/linux/dev/vmnet7 crw-r--r-- 1 root wheel 149, 0x00010008 Jan 10 2002 /compat/linux/dev/vmnet8 crw-r--r-- 1 root wheel 149, 0x00010009 Jan 10 2002 /compat/linux/dev/vmnet9 a21p% ls -l /dev/tap? crw--- 1 root network 149, 0 Aug 6 2002 /dev/tap0 crw--- 1 root network 149, 1 Aug 6 2002 /dev/tap1 crw--- 1 root network 149, 2 Aug 6 2002 /dev/tap2 crw--- 1 root network 149, 3 Aug 6 2002 /dev/tap3 crw--- 1 root network 149, 4 Dec 11 2001 /dev/tap4 crw--- 1 root network 149, 5 Dec 11 2001 /dev/tap5 crw--- 1 root network 149, 6 Dec 11 2001 /dev/tap6 crw--- 1 root network 149, 7 Dec 11 2001 /dev/tap7 a21p% Then echo -n > /compat/linux/dev/vmnetX and ifconfig will list it. In -current they just show up. Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFR: bridge locking
Daniel C. Sobral writes: | Doug Ambrisko wrote: | > Daniel C. Sobral writes: | > | If you get bridge to send/receive packets to/from vlan interfaces | > | attached to them, I'll be forever grateful. | > | | > | I've been trying to configure a setup where a firewall is connected to | > | redundant switches, but no solution I found could handle the vlan | > | attachments. :-( | > | > I assuming you are using SW VLANs then you need this. There is supposed | > to be work to fix this correctly in progress but this works for | > me when bridging VLANs. | | This didn't work for me. I don't know if I'm using SW or HW vlans. But | since I can see the vlan packets with tcpdump, I tend to believe it | would be SW vlans. | | The test I'm doing is the following: | | kldload bridge | sysctl net.link.ether.bridge=1 | sysctl net.link.ether.bridge_cfg="fxp1 fxp3" | ifconfig fxp1 up | ifconfig fxp3 up | ifconfig vlan0 create | ifconfig vlan0 vlan 999 vlandev fxp1 | ifconfig vlan0 200.220.254.190/26 | | On the switch side, the port connected to fxp1 is down and the one | connected to fxp3 is up. Next, I ping all around. What I see with your | patch is: | | ARP packets received on fxp3 go to fxp1 but not vlan0. | ARP packets sent through vlan0 go to fxp1 but not fxp3. | | This is 4.7-RELEASE. The patch did not apply cleanly, but I went through | it and fixed all failed chunks. | | (yes, this is pretty much like the other message I sent -- the results | were the same, but then I wondered if I hadn't made an error in one of | the above steps and went back to test it again, so, in the mean time, I | copied the above to the other message, adjusted, and set that reply. :) No my mistake ... I was thinking you were trying to bridge the traffic out of the FreeBSD vlan device. That is what my patch fixes. Sorry. For kicks you could try netgraph bridging. I found it sometimes works better. Tweak the script in /usr/share/example/netgraph. For some purposes I use bridge others I use the netgraph version. Depends on the need. FWIW I have created a vmnet iface then bridged to it. However, for it to work with netgraph you need to make it work. I use vmnet since it is persistant and I can just do an echo -n > /dev/vmnet1 to create it. Then I can do various things to it. So you could run the vlan off vmnet1 and then bridge it to the others. Doug A. Index: if_tap.c === RCS file: /cvs/src/sys/net/if_tap.c,v retrieving revision 1.3.2.3 diff -c -r1.3.2.3 if_tap.c *** if_tap.c14 Apr 2002 21:41:48 - 1.3.2.3 --- if_tap.c22 Aug 2003 00:08:45 - *** *** 426,431 --- 426,432 return (dummy); case SIOCSIFFLAGS: /* XXX -- just like vmnet does */ + tapifinit(tp); case SIOCADDMULTI: case SIOCDELMULTI: break; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFR: bridge locking
Daniel C. Sobral writes: | Err... ... I don't know what a vmnet is, and "apropos" told me no | tales. :-) man tap | Alas, I tried netgraph to. It suffers from about the same problem. | Packets on the bridge do not go to the vlan, and packets from the vlan | do not get sent to the bridged interfaces (just the attached one). | | I tried ng_iface, but vlan won't attach to that. | | Someone mentioned ng_eiface, which, from the looks of it, has potential. | Unfortunately, there's no documentation on it, so I don't have any idea | on how to use it. Tell, me about. I couldn't figure out how to use it so I just tie a vmnet device to it (but after 4.6 you need the tap patch) ... BTW a hint was in the patch file since the patch was to if_tap.c. a21p% uname -a FreeBSD a21p 4.8-STABLE FreeBSD 4.8-STABLE #1: Thu Aug 7 22:08:31 PDT 2003 [EMAIL PROTECTED]:/data/home/ambrisko/stable/usr/src/sys/compile/THINK i386 a21p% man ng_eiface No manual entry for ng_eiface a21p% Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ste(4) NIC's RX ring head may get ahead of the driver [PATCH]
Ruslan Ermilov writes: | To make the long story short, under a heavy RX load, the ste(4) NIC's | RX ring head may get ahead of what driver thinks, bringing all sort | of havoc like stuck traffic, disordered packets, etc. The NIC never | gets out of this state, and the only workaround is to reset the chip, | and so we did for some time (by adding the IFF_LINK2 handler to call | the driver's watchdog function). We never experienced this in our testing or in production. We were using the 4 port card. Maybe this bug is on another variant of the chip. | We've adopted the approach used by dc(4) and xl(4), but instead of | seeing if we need to re-synchronize the head _after_ receiving (like | dc(4) and xl(4) drivers do), we do it at the beginning of ste_rxeof(). | As statistics shows, the number of resyncs needed is smaller by a | factor of 3 or more in this case, because often the RxDMAComplete | interrupt is generated when RX ring is completely empty(!), and as | NIC continues to do DMA and fill the RX ring while we're still | servicing the RxDMAComplete interrupt, we did more resyncs than was | actually necessary. Sounds good. | Also, we were able to further reduce the number of resyncs by setting | the RxDMAPollPeriod to a higher value. 320ns looked like an overkill | here, and I'm not sure why you have chosen it in the first place, | when adding polling support for RX in the driver. Also, we believe | that this setting may be responsible for what you referred to as: I'm not sure. | > This card still has seemingly unfixable issues under heavy RX load in | > which the card takes over the PCI bus. | | in the commit log for revision 1.33 of if_ste.c. | | Attached is the patch (for RELENG_4) we're currently using, and are | quite happy with. If anyone is using ste(4) NICs and is experiencing | similar problems, I'd be glad to hear the reports about this patch. Sounds good. However it won't fix the core problem that I reported. D-Link's solution was to EOL 4-port card because of this problem. You can see it in their Linux and Windows drivers. The easiest way to see it is to send traffic into all 4 ports of the 4 port card. You will see only one port have activity then it switch to another. It will not be multiplexing traffic. Another thing I found that would lead to a panic was that if you reset the chip while it is sending traffic into the card the reset will return but the card still takes RX packets and DMA's them into memory. Since it we have released the memory for the card it would then splat bits over something else. It was a while before I figure out this cause of panics :-( I don't see how your change will fix that. I no longer have access to the HW or the test environment I used since I've changed jobs. I have no objection to your change and it sounds good. I don't think it will solve the problem I saw. While you are in this driver can you convert it to Mike Silby's generic de-frager? To test it do some like: dd if=/kernel bs=1 | ssh "cat > /tmp/kernel" I original "stole" the code to do this from fxp(4) which was before Mike did the generic de-frager. Thanks, Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
