Re: interface FIB
On Fri, Nov 27, 2009 at 09:12:37PM -0800, Julian Elischer wrote: > Igor Sysoev wrote: > > Currently only packets generated during encapsulation can use > > interface's FIB stored during interface creation: > > > > setfib 1 ifconfig gif0 ... > > setfib 1 ifconfig tun0 ... > > not sure if tun actually does this (in fac tit shouldn't) > > but for gre and gif (and stf) these are tunnelling other things into > IP and thus it makes sense to be able to connect a routing table with > the generated envelopes. I've got this from 8.0 release notes: A packet generated on tunnel interfaces such as gif(4) and tun(4) will be encapsulated using the FIB of the process which set up the tunnel. However, sys/net/if_tun.c is really has no FIB related changes. > > is it possible to implement this feature for any interface: > > > > setfib 1 ifconfig vlan0 ... > > > > or > > > > ifconfig vlan0 setfib 1 ... > > these two things would mean differnt things. > and one of them wouldn't mean anything. > > setfig 1 ifconfig vlan0 woudl mean "what" exactly? > VLAN tagging is an L2/L1 operation and FIBS have no effect on this. > > as for ifconfig vlan0 setfib 1, or ifconfig em0 setfib 1 > > this will (shortly) mean that incoming packets through this interface > will be default be connected with fib 1 so the any return packets > (resets, icmp etc.) will use FIB1 to go back to the sender. This is exactly what I meant. > That patch is in the works. I'm ready to test the patch in production on 7/8-STABLE if the patch can be applied to it. -- Igor Sysoev http://sysoev.ru/en/ ___ 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"
Fix available for run driver
Hello, There are some fixes for run driver for 8.0 release and current. It can be downloaded from freebsd forums at http://forums.freebsd.org/showpost.php?s=87e376cf71273061f7de5aaf258132a1&p=44110&postcount=1 Some packet loss/drop and memory leak have been identified and fixed. (It improved some performance, too) Also, 40 more vender/device IDs have been added. Details are on RELEASE_NOTES included. Please update before the driver causing any troubles. Akinori __ Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ ___ 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: kern/140970: [bce] The two NetXtreme II BCM5709S NICs on our HP Bl460c G1 Blade can't be accessed on FreeBSD 7.2 and 8 [regression]
Old Synopsis: [bce] The two NetXtreme II BCM5709S NICs on our HP Bl460c G1 Blade can't be accessed on FreeBSD 7.2 and 8 New Synopsis: [bce] The two NetXtreme II BCM5709S NICs on our HP Bl460c G1 Blade can't be accessed on FreeBSD 7.2 and 8 [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Nov 28 15:26:24 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140970 ___ 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: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock
Hi, On Mon, Nov 23, 2009 at 9:30 PM, Benjamin Kaduk > > On Sun, 22 Nov 2009, Bernhard Schmidt wrote: > >> > >> Can you verify that the LOR is gone with the latest checkout of my > >> repository? > >> Compile instructions: > >> http://forums.freebsd.org/showpost.php?p=47627&postcount=16 > > > > I upgraded to today's current (which picked up a number of > probably-unrelated > > changes), and then installed the driver from > > your tree on top of it. > > No LOR on boot, and I'll let you know if I see any lockups. I am seeing this LOR on 8-STABLE (with the latest iwn(4) patches from the site above). > > > I got a "lockup" (no idea what actually was happening) while in X tonight; > nothing useful is in the logs. Do you mean "lockup" as in the system becomes non-responsive? If so, I am experiencing this as well. I recently switched my filesystem to ZFS because of the time fsck_ufs takes, and added the following options to GENERIC to try to track this down: KDB DDB BREAK_TO_DEBUGGER ALT_BREAK_TO_DEBUGGER INVARIANTS INVARIANT_SUPPORT WITNESS WITNESS_SKIPSPIN SOCKBUF_DEBUG DIAGNOSTIC SW_WATCHDOG DEBUG_VFS_LOCKS > I'm not even sure if I can blame iwn for it ... The last time the system locked, I wasn't in X. I saw the following on the console before it became unusable: firmware error log: error type = "SYSASSERT" (0x0005) program counter = 0xC920 source line = 0x0619 error data = 0x00FE branch link = 0xC842C842 interrupt link = 0x090E time= 1182627 driver status: tx ring 0: qid=0 cur=1 queued=1 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=0 queued=0 tx ring 4: qid=4 cur=12 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=0 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 tx ring 16: qid=16 cur=0 queued=0 tx ring 17: qid=17 cur=0 queued=0 tx ring 18: qid=18 cur=0 queued=0 tx ring 19: qid=19 cur=0 queued=0 rx ring: cur=59 iwn0: iwn_apm_stop_master: timeout waiting for master If there is more information I can provide, please let me know. -- Glen Barber ___ 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"
