Re: Marvell/SysKonnect YukonII source code available
Pyun YongHyeon wrote: On Tue, Jan 24, 2006 at 11:19:05AM +0100, Andre Oppermann wrote: > Marvell/SysKonnect made the source code to the YukonII chips available > today under a BSD license: > > http://people.freebsd.org/~andre/mykbsd60x86-8.12.1.3-src.tgz > > I haven't tested the driver yet and I don't know if it available directly > from the their website already. > > Many thanks to Gerald and Frank at SysKonnect for working with us and > making this possible! > Yes, that's great news. Is there any chance to get a copy of data sheet for Yukon chips? If you are willing and able to sign a NDA for the 'physical' docs I think so. Using the obtained knowledge in a driver is not longer a problem as pretty much all of the information is available in the BSD licensed OSS driver too. It's just a bit harder to digest w/o the documentation. Ie. now that the driver is OSS there are no more trade secrets in the chip. I've tried hard to make Rx TCP/UDP checksum offload work but failed. ATM both Linux and OpenBSD use Rx IP checksum offload only but this driver enabled Rx checksum offload for TCP/UDP. So I guess there is somthing not listed in SK-NET Genesis data sheet. :-( Likely. Quick reading the source shows that this driver has the following issues. 1. Incomplete bus_dma(9) support. The driver uses BUS_SPACE_MAXADDR when it creates DMA tags which means its DMA supports any address without limitations. However, I'm sure Rx/Tx descriptors should reside in < 4GB. So the driver wouldn't work on systems with > 4GB memory. 2. Since the driver makes use of mbpool(9) it wouldn't work when bounce buffers are involved. In fact, I think the use of mbpool(9) is really bad as it lacks bus_dmamap_sync(9) operation. 3. Lack of ALTQ support. 4. The driver may not work on big-endian architectures. 5. The driver may not work on architectures with strict-alignment. Yes, they haven't spent all the time to get up-to-date with FreeBSD. It seems most of their time is spent on OSX and Solaris drivers for new wired and wireless chips. Btw, new sk(4) is availabe at the following URL. Due to lack of documentation it doesn't support YukonII yet. http://people.freebsd.org/~yongari/sk/if_sk.c http://people.freebsd.org/~yongari/sk/if_skreg.h What's the differences to our current sk(4)? -- Andre ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: re0: 2 link states coalesced.
Julien Gabel wrote: Hello Hans, I have a problem with my RTL8169 Gigabit NIC built into my (apparently very uncommon) Clevo D41EV laptop. At boot, when netif tries to set up the interface, I get a lot of these messages: > re0: 2 link states coalesced > re0: link state changed to DOWN > re0: 2 link states coalesced > re0: link state changed to DOWN > re0: 2 link states coalesced > re0: link state changed to DOWN I filled one a year ago, for the very same problem (encountered for two years now). See Problem Report kern/80005 for more information. I think that another user (Emmanuel Duros) tried to speak with Realtek on that point, not sure if there is feedback on it though... Sorry not to have better news. That's too bad, but thanks for letting me know ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Race condition in ip6_getpmtu?
I seem to be running into a race condition in ip6_getpmtu. I've been
having sporadic panics recently -- sometimes the machine will last a
week, sometimes it'll panic twice in a day. The backtrace is always the
same:
(ddb and doadump frames removed)
#9 0xc066548a in calltrap () at /compile/src/sys/i386/i386/exception.s:139
#10 0xc05d32f1 in ip6_getpmtu (ro_pmtu=0xc528a90c, ro=0xc528a90c,
ifp=0xc4fea800, dst=0xe886b964, mtup=0x0, alwaysfragp=0xe886b8e4)
at /compile/src/sys/netinet6/ip6_output.c:1415
#11 0xc05d2197 in ip6_output (m0=0xc528a90c, opt=0x0, ro=0xc528a90c, flags=4,
im6o=0x0, ifpp=0x0, inp=0x0) at /compile/src/sys/netinet6/ip6_output.c:806
#12 0xc05c74d4 in in6_gif_output (ifp=0xc51ae400, family=-971248640,
m=0xc5362900) at /compile/src/sys/netinet6/in6_gif.c:216
#13 0xc05900cb in gif_output (ifp=0xc51ae400, m=0xc52d4400, dst=0xc51b1a50,
rt=0xc543e084) at /compile/src/sys/net/if_gif.c:435
#14 0xc05a75f0 in ip_output (m=0xc52d4400, opt=0xc51ae400, ro=0xe886baac,
flags=0, imo=0x0, inp=0xc6189bf4)
at /compile/src/sys/netinet/ip_output.c:776
#15 0xc05b1828 in tcp_output (tp=0xc6060c94)
at /compile/src/sys/netinet/tcp_output.c:1080
#16 0xc05b99ca in tcp_usr_rcvd (so=0x0, flags=0)
at /compile/src/sys/netinet/tcp_usrreq.c:600
#17 0xc055129b in soreceive (so=0xc61b3de8, psa=0x0, uio=0xe886bcb0, mp0=0x0,
controlp=0x0, flagsp=0x0) at /compile/src/sys/kern/uipc_socket.c:1400
#18 0xc053c63f in soo_read (fp=0x0, uio=0x0, active_cred=0xc61c7e00, flags=0,
td=0xc61bec00) at /compile/src/sys/kern/sys_socket.c:91
... all the way back to read(), though sometimes it will be in write()
(kgdb) up 10
#10 0xc05d32f1 in ip6_getpmtu (ro_pmtu=0xc528a90c, ro=0xc528a90c,
ifp=0xc4fea800, dst=0xe886b964, mtup=0x0, alwaysfragp=0xe886b8e4)
at /compile/src/sys/netinet6/ip6_output.c:1415
1415mtu = ro_pmtu->ro_rt->rt_rmx.rmx_mtu;
(kgdb) print ro_pmtu
$1 = (struct route_in6 *) 0xc528a90c
(kgdb) print ro_pmtu->ro_rt
$2 = (struct rtentry *) 0x0
But... That line is in a block where ro_rt has already been checked to see if
it's null.
1400if (ro_pmtu->ro_rt) {
...
1412if (mtu)
1413mtu = min(mtu, ro_pmtu->ro_rt->rt_rmx.rmx_mtu);
1414else
1415mtu = ro_pmtu->ro_rt->rt_rmx.rmx_mtu;
...
1441} else if (ifp) {
So, somehow ro_pmto->ro_rt is being set to null between line 1400 and
1415. The only function call inside the block is tcp_hc_getmtu(), and
that doesn't touch the routing table. My guess is that it's being
preempted by another process and the cached neighbor entry is expiring.
I don't see any locks protecting ro_pmtu, however I'm unfamiliar with
how locking in the IP6 code works so there may be one higher up.
The traffic in question is IPv4 traffic going out over an IPv6 gif
tunnel. So far it always seems to happen when trying to send an
encapsulated packet.
Any IPv6 gurus know if that's a reasonable theory?
Thanks,
Craig
-
Addendum: While writing this message, it panic'd again. However this
time it was in a delayed ACK transmission (still for the gif tunnel
though).
#10 0xc05d32f1 in ip6_getpmtu (ro_pmtu=0xc51ecc0c, ro=0xc51ecc0c,
ifp=0xc4fea800, dst=0xe3938a2c, mtup=0x0, alwaysfragp=0xe39389ac)
at /compile/src/sys/netinet6/ip6_output.c:1415
#11 0xc05d2197 in ip6_output (m0=0xc51ecc0c, opt=0x0, ro=0xc51ecc0c, flags=4,
im6o=0x0, ifpp=0x0, inp=0x0) at /compile/src/sys/netinet6/ip6_output.c:806
#12 0xc05c74d4 in in6_gif_output (ifp=0xc51af400, family=-991434496,
m=0xc53a9d00) at /compile/src/sys/netinet6/in6_gif.c:216
#13 0xc05900cb in gif_output (ifp=0xc51af400, m=0xc53ef900, dst=0xc51ad970,
rt=0xc5439084) at /compile/src/sys/net/if_gif.c:435
#14 0xc05a75f0 in ip_output (m=0xc53ef900, opt=0xc51af400, ro=0xe3938b74,
flags=0, imo=0x0, inp=0xc61484ec)
at /compile/src/sys/netinet/ip_output.c:776
#15 0xc05b1828 in tcp_output (tp=0xc6cf3398)
at /compile/src/sys/netinet/tcp_output.c:1080
#16 0xc05b71c2 in tcp_timer_delack (xtp=0xc6cf3398)
at /compile/src/sys/netinet/tcp_timer.c:175
#17 0xc051cb83 in softclock (dummy=0x0)
at /compile/src/sys/kern/kern_timeout.c:290
#18 0xc04f5e90 in ithread_loop (arg=0xc4ee5280)
...
Exact same spot in ip6_getpmtu though.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gif interface listener problem?
Hello, One of my servers still runs FreeBSD 4.11. It has two internet connections from two different providers. First of them is used for common internet access and the second is dedicated for a tunnel between offices. Lets mark IPs in this way rl0 - main interface rl1 - tunnel interface xxx.xxx.xxx.xxx - IP of main internet interface XXX.XXX.XXX.XXX - IP of gateway for main interface yyy.yyy.yyy.yyy - IP of tunnel interface YYY.YYY.YYY.YYY - IP of gateway for tunnel interface zzz.zzz.zzz.zzz - IP of endpoint for tunnel I have configured policy routing using ipfw in a such way (simplifyed): add fwd YYY.YYY.YYY.YYY all from yyy.yyy.yyy.yyy out xmit rl0 add fwd XXX.XXX.XXX.XXX all from xxx.xxx.xxx.xxx out xmit rl1 add allow ipencap from any to any via rl1 add allow all from any to any via gif0 ... gif tunnel is configured in a such way: gif0: flags=8051 mtu 1280 tunnel inet yyy.yyy.yyy.yyy --> zzz.zzz.zzz.zzz inet 192.168.200.1 --> 192.168.201.1 netmask 0x The default route is to XXX.XXX.XXX.XXX if a route zzz.zzz.zzz.zzz -> YYY.YYY.YYY.YYY is manually created, everything works fine. But in this case ALL traffic to host zzz.zzz.zzz.zzz is routed through rl1 interface and this is unacceptable as all of rl1 bandwidth is reserved for tunneling important interactive data. If there is no manual route we have (dumping rl1 interface): - all outgoing ipencap traffic goes well - all incoming traffic comes in rl1 but is lost (gif0 interface is empty) It seems that gif interface listens for ipencap on the interface that is on route to destination but not at its source (yyy.yyy.yyy.yyy in my case). How can I force gif to listen on correct interface? Maybe this is corrected in later versions of FreeBSD? Should I upgrade that box? -- Best regards, Oleg Tarasov mailto:[EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Policy routing and multipath routing needed (override routing table)
Hello, Many people know how to engage policy routing using ipfw forward function. This can be successfully used on simple routers (not NAT gateways) and to make gateways with multiple internet connections provide services (such as DNS, mail etc) on all interfaces. But the difficulty comes when the box itself is the source of packets. For example when mail server sends mail to another server. In this case the source ip of packets is calculated using routing table based on the destination address. These packets can't be correctly routed using policy as in this case we should probably pass these packets through NAT that is not always acceptable and is difficult to perform using standart tools as forwarded packets are not injected into firewall to be diverted through NAT. The easiest way to show this need is a simple planning of interface load division between internet interfaces based on services (for ex. proxy, dns, mail, ftp etc). In this case simple routing table can not provide what we need. The second thing to be mentioned is known as multipath routing. It is a special situation of policy routing but is more easy to develope. It can solve some problems too. I have found a mentioning of developing these functions as "planned" by FreeBSD developers in march 2004 (http://kerneltrap.org/node/2593). The obvious solution of this problem lies in using of Cisco router but this is not good for medium-size business organization due to lack of funds (you know those bosses) as thas router costs like another routing machine ;) It would be great to hear from core team of their plans regarding this network stack changes. There is another problem. In my opinion it should be great to make one more attribute to routes in routing table indicating of their activity/inactivity. The source of this problem is that all static routes on reconfigured interface are deleted as ip changes. If this reconfiguration occurs we need to recreate these routes again. It would be great if they would persisted and for that time were "inactive". One of the solutions in this case would be a tool for monitoring interface state able to activate some script on state change. This would be great for failover for example. Please enlight me and tell if there is any. -- Best regards, Oleg Tarasov mailto:[EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Failover and load balancing using advanced NAT daemon
Hello, I have an idea of implementation of this common task. Please tell me if there is some alternative or use my idea to implement advanced NAT daemon (this would be great). Maybe it would be good to upgrade standart natd daemon. The task: We have several interfaces connected to internet and all having static IPs and one (or more) interfaces to local network. We must provide NATed internet access to local network users load-balancing internet interfaces and providing failover. All session have to "remember" their outgoing interface as one session will break if packets start to come from different IPs. A way to perform this: - We need to monitor interface state (some simple like up/down) or more complex like periodic gateway ping for example. - We need to measure interface load - We need NAT that aliases outgoing connections to one of these interfaces - We need to route outgoing packets based on source IP assigned by NAT. This can be performed using ipfw forward mechanism. First three functions would be great to be implemented inside one daemon like standart natd. Packets should be diverted into it. This daemon can easily perform all of the tasks listed above as all of the packets are passed through it. Using it in a combination with policy-routing would be a powerful mechanism! -- Best regards, Oleg Tarasov mailto:[EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Failover and load balancing using advanced NAT daemon
Hey there Oleg, I have done something similar with 2 internet interfaces, but I use very crude IPFW rules to "remember" sessions. I have a seperate natd running for each interface, but my setup includes mail, web and pptp servers on the LAN which complicates matters. I did not have load balancing but am using a ping script to monitor interfaces and re-route traffic using ipfw set's which get enabled and disabled. This ping script could be modified to calculate ping times and shift load by the same method - but that's _really_ rough. I am sure there are much more elegant ways of doing this though. Keep us posted! Graham Oleg Tarasov wrote: Hello, I have an idea of implementation of this common task. Please tell me if there is some alternative or use my idea to implement advanced NAT daemon (this would be great). Maybe it would be good to upgrade standart natd daemon. The task: We have several interfaces connected to internet and all having static IPs and one (or more) interfaces to local network. We must provide NATed internet access to local network users load-balancing internet interfaces and providing failover. All session have to "remember" their outgoing interface as one session will break if packets start to come from different IPs. A way to perform this: - We need to monitor interface state (some simple like up/down) or more complex like periodic gateway ping for example. - We need to measure interface load - We need NAT that aliases outgoing connections to one of these interfaces - We need to route outgoing packets based on source IP assigned by NAT. This can be performed using ipfw forward mechanism. First three functions would be great to be implemented inside one daemon like standart natd. Packets should be diverted into it. This daemon can easily perform all of the tasks listed above as all of the packets are passed through it. Using it in a combination with policy-routing would be a powerful mechanism! ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Failover and load balancing using advanced NAT daemon
On 1/25/06, Oleg Tarasov <[EMAIL PROTECTED]> wrote: > First three functions would be great to be implemented inside one > daemon like standart natd. Packets should be diverted into it. This > daemon can easily perform all of the tasks listed above as all of the > packets are passed through it. > > Using it in a combination with policy-routing would be a powerful > mechanism! You may want to check out PF, the packet filter imported from OpenBSD. I have it running on some large routers doing NAT out multiple interfaces, load balancing and policy routing. Careful use of anchors and some scripting (or ifstated which might be in ports) can move traffic off failed links or respond to changing loads. I've done a lot with both ipfw and PF now, and I'm finding PF to be more flexible for my uses. -- Jon Simola Systems Administrator ABC Communications ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Question on IFF_PPROMISC (and IFF_PROMISC)
Hi, I found a (somewhat old) post from gnn@ on this topic there : http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2004-09/0289.html I also think that it would be a good idea to do it (at least, it would be easier to understand, because IFF_PPROMISC is not that explicit). If nobody has already done it, I'll work on this. There is another point on which I would appreciate to know your opinion: referring to if.c[1269], I understand that if IFF_PPROMISC is set in ifp->if_flags, IFF_PROMISC should be set to (or we are in a transient situation). It appears that if_ethersubr.c[652] is working in this case. Isn't it a mistake ? Thanks a lot ! -- Gregory PS : Gleb, Jon, thanks for your answers on vlan. It helped a lot :) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Marvell/SysKonnect YukonII source code available
On Tue, 24 Jan 2006 11:19:05 +0100 Andre Oppermann <[EMAIL PROTECTED]> wrote: > Marvell/SysKonnect made the source code to the YukonII chips > available today under a BSD license: > > http://people.freebsd.org/~andre/mykbsd60x86-8.12.1.3-src.tgz > > I haven't tested the driver yet and I don't know if it available > directly from the their website already. > > Many thanks to Gerald and Frank at SysKonnect for working with us > and making this possible! Who would one send bug reports too? I have a 88E8053 in a laptop with a releng_6 install that is up to date as of saturday. The status of the connection does not change off of "no carrier". ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
