Realtek 8111F
I installed freebsd 9.0_amd64 and it can't find my network. i tried to add "if_re_load="YES"" But it didn't help. Is the Realtek 8111F not suported by freebsd yet? Motherboard: ASUS P8H77-I ___ 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: Some performance measurements on the FreeBSD network stack
On 19.04.2012 22:46, Luigi Rizzo wrote: On Thu, Apr 19, 2012 at 10:05:37PM +0200, Andre Oppermann wrote: On 19.04.2012 15:30, Luigi Rizzo wrote: I have been running some performance tests on UDP sockets, using the netsend program in tools/tools/netrate/netsend and instrumenting the source code and the kernel do return in various points of the path. Here are some results which I hope you find interesting. - another big bottleneck is the route lookup in ip_output() (between entries 51 and 56). Not only it eats another 100ns+ on an empty routing table, but it also causes huge contentions when multiple cores are involved. This is indeed a big problem. I'm working (rough edges remain) on changing the routing table locking to an rmlock (read-mostly) which i was wondering, is there a way (and/or any advantage) to use the fastforward code to look up the route for locally sourced packets ? I've completed the updating of the routing table rmlock patch. There are two steps. Step one is just changing the rwlock to an rmlock. Step two streamlines the route lookup in ip_output and ip_fastfwd by copying out the relevant data while only holding the rmlock instead of obtaining a reference to the route. Would be very interesting to see how your benchmark/profiling changes with these patches applied. http://svn.freebsd.org/changeset/base/234649 Log: Change the radix head lock to an rmlock (read mostly lock). There is some header pollution going on because rmlock's are not entirely abstracted and need per-CPU structures. A comment in _rmlock.h says this can be hidden if there were per-cpu linker magic/support. I don't know if we have that already. http://svn.freebsd.org/changeset/base/234650 Log: Add a function rtlookup() that copies out the relevant information from an rtentry instead of returning the rtentry. This avoids the need to lock the rtentry and to increase the refcount on it. Convert ip_output() to use rtlookup() in a simplistic way. Certain seldom used functionality may not work anymore and the flowtable isn't available at the moment. Convert ip_fastfwd() to use rtlookup(). This code is meant to be used for profiling and to be experimented with further to determine which locking strategy returns the best results. Make sure to apply this one as well: http://svn.freebsd.org/changeset/base/234648 Log: Add INVARIANT and WITNESS support to rm_lock locks and optimize the synchronization path by replacing a LIST of active readers with a TAILQ. Obtained from:Isilon Submitted by: mlaier -- Andre ___ 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: Some performance measurements on the FreeBSD network stack
On Tue, Apr 24, 2012 at 03:16:48PM +0200, Andre Oppermann wrote: > On 19.04.2012 22:46, Luigi Rizzo wrote: > >On Thu, Apr 19, 2012 at 10:05:37PM +0200, Andre Oppermann wrote: > >>On 19.04.2012 15:30, Luigi Rizzo wrote: > >>>I have been running some performance tests on UDP sockets, > >>>using the netsend program in tools/tools/netrate/netsend > >>>and instrumenting the source code and the kernel do return in > >>>various points of the path. Here are some results which > >>>I hope you find interesting. > >>>- another big bottleneck is the route lookup in ip_output() > >>> (between entries 51 and 56). Not only it eats another > >>> 100ns+ on an empty routing table, but it also > >>> causes huge contentions when multiple cores > >>> are involved. > >> > >>This is indeed a big problem. I'm working (rough edges remain) on > >>changing the routing table locking to an rmlock (read-mostly) which > > > >i was wondering, is there a way (and/or any advantage) to use the > >fastforward code to look up the route for locally sourced packets ? > > I've completed the updating of the routing table rmlock patch. There > are two steps. Step one is just changing the rwlock to an rmlock. > Step two streamlines the route lookup in ip_output and ip_fastfwd by > copying out the relevant data while only holding the rmlock instead > of obtaining a reference to the route. > > Would be very interesting to see how your benchmark/profiling changes > with these patches applied. If you want to give it a try yourself, the high level benchmark is just the 'netsend' program from tools/tools/netrate/netsend -- i am running something like for i in $X ; do netsend 10.0.0.2 18 0 5 & done and the cardinality of $X can be used to test contention on the low layers (routing tables and interface/queues). >From previous tests, the difference between flowtable and routing table was small with a single process (about 5% or 50ns in the total packet processing time, if i remember well), but there was a large gain with multiple concurrent processes. Probably the change in throughput between HEAD and your branch is all you need. The info below shows that your gain is something around 100-200 ns depending on how good is the info that you return back (see below). My profiling changes were mostly aimed at charging the costs to the various layers. With my current setting (single process i7-870 @2933 MHz+Turboboost, ixgbe, FreeBSD HEAD, FLOWTABLE enabled, UDP) i see the following: FileFunction/descriptionTotal/delta nanoseconds user programsendto()8 96 system call uipc_syscalls.c sys_sendto104 uipc_syscalls.c sendit111 uipc_syscalls.c kern_sendit 118 uipc_socket.c sosend uipc_socket.c sosend_dgram 146 137 sockbuf locking, mbuf alloc, copyin udp_usrreq.cudp_send 273 udp_usrreq.cudp_output273 57 ip_output.c ip_output 330 198 route lookup, ip header setup if_ethersubr.c ether_output 528 162 MAC header lookup and construction, loopback checks if_ethersubr.c ether_output_frame690 ixgbe.c ixgbe_mq_start698 ixgbe.c ixgbe_mq_start_locked 720 ixgbe.c ixgbe_xmit730 220 mbuf mangling, device programming -- packet on the wire950 Removing flowtable increases the cost in ip_output() (obviously) but also in ether_output() (because the route does not have a lle entry so you need to call arpresolve on each packet). It also causes trouble in the device driver because the mbuf does not have a flowid set, so the ixgbe device driver puts the packet on the queue corresponding to the current CPU. If the process (as in my case) floats, one flow might end up on multiple queues. So in revising the route lookup i believe it would be good if we could also get at once most of the info that ether_output() is computing again and again. cheers luigi > http://svn.freebsd.org/changeset/base/234649 > Log: > Change the radix head lock to an rmlock (read mostly lock). > > There is some header pollution going on because rmlock's are > not entirely abstracted and need per-CPU structures. > > A comment in _rmlock.h says this can be hidden if there were > per-cpu linker magic/support. I don't know if we have that > already. > > http://svn.freebsd.org/changeset/base/234650 > Log: > Add a function rtlookup() that copies out the relevant information > from an rtentry instead of returning the rtentry. This avoids the > need to lock the rtentry and to increase the refcount on it. > > Convert ip_output() to use rtlookup() in a simplistic way. Certain > seldom used fu
RE: Some performance measurements on the FreeBSD network stack
> >From previous tests, the difference between flowtable and >routing table was small with a single process (about 5% or 50ns >in the total packet processing time, if i remember well), >but there was a large gain with multiple concurrent processes. > Yes, that sounds about right when we did the tests a long while ago. > > Removing flowtable increases the cost in ip_output() > (obviously) but also in ether_output() (because the > route does not have a lle entry so you need to call > arpresolve on each packet). > Yup. > > So in revising the route lookup i believe it would be good > if we could also get at once most of the info that > ether_output() is computing again and again. > Well, the routing table no longer maintains any lle info, so there isn't much to copy out the rtentry at the completion of route lookup. If I understood you correctly, you do believe there is a lot of value in Flowtable caching concept, but you are not suggesting we reverting back to having the routing table maintain L2 entries, are you ? --Qing ___ 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: Some performance measurements on the FreeBSD network stack
On Tue, Apr 24, 2012 at 4:16 PM, Li, Qing wrote: >> > >From previous tests, the difference between flowtable and >>routing table was small with a single process (about 5% or 50ns >>in the total packet processing time, if i remember well), >>but there was a large gain with multiple concurrent processes. >> > > Yes, that sounds about right when we did the tests a long while ago. > >> >> Removing flowtable increases the cost in ip_output() >> (obviously) but also in ether_output() (because the >> route does not have a lle entry so you need to call >> arpresolve on each packet). >> > > Yup. > >> >> So in revising the route lookup i believe it would be good >> if we could also get at once most of the info that >> ether_output() is computing again and again. >> > > Well, the routing table no longer maintains any lle info, so there > isn't much to copy out the rtentry at the completion of route > lookup. > > If I understood you correctly, you do believe there is a lot of value > in Flowtable caching concept, but you are not suggesting we reverting > back to having the routing table maintain L2 entries, are you ? > One could try a similar conversion of the L2 table to an rmlock without copy while lock is held. -Kip -- “The real damage is done by those millions who want to 'get by.' The ordinary men who just want to be left in peace. Those who don’t want their little lives disturbed by anything bigger than themselves. Those with no sides and no causes. Those who won’t take measure of their own strength, for fear of antagonizing their own weakness. Those who don’t like to make waves—or enemies. Those for whom freedom, honour, truth, and principles are only literature. Those who live small, love small, die small. It’s the reductionist approach to life: if you keep it small, you’ll keep it under control. If you don’t make any noise, the bogeyman won’t find you. But it’s all an illusion, because they die too, those people who roll up their spirits into tiny little balls so as to be safe. Safe?! >From what? Life is always on the edge of death; narrow streets lead to the same place as wide avenues, and a little candle burns itself out just like a flaming torch does. I choose my own way to burn.” Sophie Scholl ___ 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: Some performance measurements on the FreeBSD network stack
On Tue, Apr 24, 2012 at 5:03 PM, K. Macy wrote: > On Tue, Apr 24, 2012 at 4:16 PM, Li, Qing wrote: >>> >> >From previous tests, the difference between flowtable and >>>routing table was small with a single process (about 5% or 50ns >>>in the total packet processing time, if i remember well), >>>but there was a large gain with multiple concurrent processes. >>> >> >> Yes, that sounds about right when we did the tests a long while ago. >> >>> >>> Removing flowtable increases the cost in ip_output() >>> (obviously) but also in ether_output() (because the >>> route does not have a lle entry so you need to call >>> arpresolve on each packet). >>> >> >> Yup. >> >>> >>> So in revising the route lookup i believe it would be good >>> if we could also get at once most of the info that >>> ether_output() is computing again and again. >>> >> >> Well, the routing table no longer maintains any lle info, so there >> isn't much to copy out the rtentry at the completion of route >> lookup. >> >> If I understood you correctly, you do believe there is a lot of value >> in Flowtable caching concept, but you are not suggesting we reverting >> back to having the routing table maintain L2 entries, are you ? >> > > > One could try a similar conversion of the L2 table to an rmlock > without copy while lock is held. Odd .. *with* copy while lock is held. -Kip ___ 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: Some performance measurements on the FreeBSD network stack
On Tue, Apr 24, 2012 at 02:16:18PM +, Li, Qing wrote: > > > >From previous tests, the difference between flowtable and > >routing table was small with a single process (about 5% or 50ns > >in the total packet processing time, if i remember well), > >but there was a large gain with multiple concurrent processes. > > > > Yes, that sounds about right when we did the tests a long while ago. > > > > > Removing flowtable increases the cost in ip_output() > > (obviously) but also in ether_output() (because the > > route does not have a lle entry so you need to call > > arpresolve on each packet). > > > > Yup. > > > > > So in revising the route lookup i believe it would be good > > if we could also get at once most of the info that > > ether_output() is computing again and again. > > > > Well, the routing table no longer maintains any lle info, so there > isn't much to copy out the rtentry at the completion of route > lookup. > > If I understood you correctly, you do believe there is a lot of value > in Flowtable caching concept, but you are not suggesting we reverting > back to having the routing table maintain L2 entries, are you ? I see a lot of value in caching in general. Especially for a bound socket it seems pointless to lookup the route, iface and mac address(es) on every single packet instead of caching them. And, routes and MAC addresses are volatile anyways so making sure that we do the lookup 1us closer to the actual use gives no additional guarantee. The frequency with which these info (routes and MAC addresses) change clearly influences the mechanism to validate the cache. I suppose we have the following options: - direct notification: a failure in a direct chain of calls can be used to invalidate the info cached in the socket. Similarly, some incoming traffic (e.g. TCP RST, FIN, ICMP messages) that reach a socket can invalidate the cached values - assume a minimum lifetime for the info (i think this is what happens in the flowtable) and flush it unconditionally every such interval (say 10ms). - if some info changes infrequently (e.g. MAC addresses) one could put a version number in the cached value and use it to validate the cache. cheers luigi ___ 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: Some performance measurements on the FreeBSD network stack
On Tue, Apr 24, 2012 at 6:34 PM, Luigi Rizzo wrote: > On Tue, Apr 24, 2012 at 02:16:18PM +, Li, Qing wrote: >> > >> >From previous tests, the difference between flowtable and >> >routing table was small with a single process (about 5% or 50ns >> >in the total packet processing time, if i remember well), >> >but there was a large gain with multiple concurrent processes. >> > >> >> Yes, that sounds about right when we did the tests a long while ago. >> >> > >> > Removing flowtable increases the cost in ip_output() >> > (obviously) but also in ether_output() (because the >> > route does not have a lle entry so you need to call >> > arpresolve on each packet). >> > >> >> Yup. >> >> > >> > So in revising the route lookup i believe it would be good >> > if we could also get at once most of the info that >> > ether_output() is computing again and again. >> > >> >> Well, the routing table no longer maintains any lle info, so there >> isn't much to copy out the rtentry at the completion of route >> lookup. >> >> If I understood you correctly, you do believe there is a lot of value >> in Flowtable caching concept, but you are not suggesting we reverting >> back to having the routing table maintain L2 entries, are you ? > > I see a lot of value in caching in general. > > Especially for a bound socket it seems pointless to lookup the > route, iface and mac address(es) on every single packet instead of > caching them. And, routes and MAC addresses are volatile anyways > so making sure that we do the lookup 1us closer to the actual use > gives no additional guarantee. > > The frequency with which these info (routes and MAC addresses) > change clearly influences the mechanism to validate the cache. > I suppose we have the following options: > > - direct notification: a failure in a direct chain of calls > can be used to invalidate the info cached in the socket. > Similarly, some incoming traffic (e.g. TCP RST, FIN, > ICMP messages) that reach a socket can invalidate the cached values > - assume a minimum lifetime for the info (i think this is what > happens in the flowtable) and flush it unconditionally > every such interval (say 10ms). > - if some info changes infrequently (e.g. MAC addresses) one could > put a version number in the cached value and use it to validate > the cache. I have a patch that has been sitting around for a long time due to review cycle latency that caches a pointer to the rtentry (and llentry) in the the inpcb. Before each use the rtentry is checked against a generation number in the routing tree that is incremented on every routing table update. ___ 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: Some performance measurements on the FreeBSD network stack
>> > > I have a patch that has been sitting around for a long time due to > review cycle latency that caches a pointer to the rtentry (and > llentry) in the the inpcb. Before each use the rtentry is checked > against a generation number in the routing tree that is incremented on > every routing table update. Hi Kip, Is there a public location for the patch ? What can be done to speedup the commit: testing ? Fabien
RE: Some performance measurements on the FreeBSD network stack
Yup, all good points. In fact we have considered all of these while doing the work. In case you haven't seen it already, we did write about these issues in our paper and how we tried to address those, flow-table was one of the solutions. http://dl.acm.org/citation.cfm?id=1592641 --Qing > > > > Well, the routing table no longer maintains any lle info, so there > > isn't much to copy out the rtentry at the completion of route > > lookup. > > > > If I understood you correctly, you do believe there is a lot of value > > in Flowtable caching concept, but you are not suggesting we reverting > > back to having the routing table maintain L2 entries, are you ? > > I see a lot of value in caching in general. > > Especially for a bound socket it seems pointless to lookup the > route, iface and mac address(es) on every single packet instead of > caching them. And, routes and MAC addresses are volatile anyways > so making sure that we do the lookup 1us closer to the actual use > gives no additional guarantee. > > The frequency with which these info (routes and MAC addresses) > change clearly influences the mechanism to validate the cache. > I suppose we have the following options: > > - direct notification: a failure in a direct chain of calls > can be used to invalidate the info cached in the socket. > Similarly, some incoming traffic (e.g. TCP RST, FIN, > ICMP messages) that reach a socket can invalidate the cached values > - assume a minimum lifetime for the info (i think this is what > happens in the flowtable) and flush it unconditionally > every such interval (say 10ms). > - if some info changes infrequently (e.g. MAC addresses) one could > put a version number in the cached value and use it to validate > the cache. > > cheers > luigi ___ 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: Some performance measurements on the FreeBSD network stack
> > > > I have a patch that has been sitting around for a long time due to > > review cycle latency that caches a pointer to the rtentry (and > > llentry) in the the inpcb. Before each use the rtentry is checked > > against a generation number in the routing tree that is incremented > on > > every routing table update. > > Hi Kip, > > Is there a public location for the patch ? > What can be done to speedup the commit: testing ? > > Fabien I performed extensive review of this patch from Kip, and it was ready to go. Really good work. Not sure what is stopping its commit into the tree. --Qing ___ 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"
LLA (Link local address) in FreeBSD route command
Hi, I am trying to see what is valid and is supported in latest FreeBSD Does BSD let user add routes to LLA destinations? Does BSD let user specify LLA gateway without specifying the scope? I see following man page which talks about scope but looks like it not supported in the latest. http://www.manpagez.com/man/8/route/ Thanks, Satish K Amara ___ 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: Some performance measurements on the FreeBSD network stack
On 24. Apr 2012, at 17:42 , Li, Qing wrote: >>> >>> I have a patch that has been sitting around for a long time due to >>> review cycle latency that caches a pointer to the rtentry (and >>> llentry) in the the inpcb. Before each use the rtentry is checked >>> against a generation number in the routing tree that is incremented >> on >>> every routing table update. >> >> Hi Kip, >> >> Is there a public location for the patch ? >> What can be done to speedup the commit: testing ? >> >> Fabien > > I performed extensive review of this patch from Kip, and it was > ready to go. Really good work. > > Not sure what is stopping its commit into the tree. Because there were leaks, there were 100% panics for IPv6, ... at least on the version I had seen in autumn last year. There is certainly no one more interested then me on these in, esp. for v6 where the removal of route caching a long time ago made nd6_nud_hint() a NOP with dst and rt being passed down as NULL only, and where we are doing up to three route lookups in the output path if no cached rt is passed down along from the ULP. If there is an updated patch, I'd love to see it. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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"
igb(4) Pondering a bind to cpu patch
http://people.freebsd.org/~sbruno/if_igb.c.txt Scenario I've just seen: 8 core machine 2 igb(4) interfaces set num_queues=4 igb0:0 --> cpu0 igb0:1 --> cpu1 igb0:2 --> cpu2 igb0:3 --> cpu3 igb1:0 --> cpu0 igb1:1 --> cpu1 igb1:2 --> cpu2 igb1:3 --> cpu3 I suspect, that we need a static global to keep track of what cpu last was last bound to a queue. My patch does do this, but I don't know if its the right thing. Since I'm doing multiple interfaces, I need to make sure I don't schedule a queue to a non existent cpu, so take a modulo of the counter and the number of cpus in the box. Perhaps not the most elegant solution, but its a thing? Sean ___ 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: igb(4) Pondering a bind to cpu patch
On Tue, Apr 24, 2012 at 17:11, Sean Bruno wrote: > http://people.freebsd.org/~sbruno/if_igb.c.txt > > 8 core machine > 2 igb(4) interfaces > set num_queues=4 > > igb0:0 --> cpu0 > [...] > igb1:0 --> cpu0 > [...] > > I suspect, that we need a static global to keep track of what cpu last > was last bound to a queue. My patch does do this, but I don't know if > its the right thing. > > Since I'm doing multiple interfaces, I need to make sure I don't > schedule a queue to a non existent cpu, so take a modulo of the counter > and the number of cpus in the box. This seems like a plausible approach, and certainly much more DWIM than what I've done in the past, which is to use cpuset with -x to bind each IRQ to a core by hand. If there were a way for interfaces to export queue information including any relevant IRQs, it would be easy to make a frontend that would use cpuset in a usable way, but right now that's the solution I've found most tenable and uninvasive. The question here is what behavior to assume the user wants when they restrict the number of queues, which is why putting the policy bits into userland would be preferable to this sort of scheme, I suppose. ___ 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/164569: [msk] [hang] msk network driver cause freeze in FreeBSD 9.0 i386
Synopsis: [msk] [hang] msk network driver cause freeze in FreeBSD 9.0 i386 State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Wed Apr 25 03:31:01 UTC 2012 State-Changed-Why: Would you show me the output of both dmesg(8) and 'pciconf -lcbv'? Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Wed Apr 25 03:31:01 UTC 2012 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=164569 ___ 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: LLA (Link local address) in FreeBSD route command
First off lets start by referencing something that is correct and staying within-band instead of OOB. http://www.freebsd.org/cgi/man.cgi?query=route Review that page and if you still have any questions then please ask again. On Tue, Apr 24, 2012 at 05:07:54PM -0400, satish amara wrote: > Hi, > >I am trying to see what is valid and is supported in latest > FreeBSD > > Does BSD let user add routes to LLA destinations? > > Does BSD let user specify LLA gateway without specifying the scope? > > > I see following man page which talks about scope but looks like it not > supported in the latest. > > http://www.manpagez.com/man/8/route/ > > > Thanks, > > Satish K Amara > ___ > 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" -- - (2^(N-1)) pgpJKNIov89iP.pgp Description: PGP signature
Re: kern/157429: [re] Realtek RTL8169 doesn't work with re(4)
Synopsis: [re] Realtek RTL8169 doesn't work with re(4) State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Wed Apr 25 04:29:45 UTC 2012 State-Changed-Why: Try diff at the following URL and let me know how it goes. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Wed Apr 25 04:29:45 UTC 2012 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=157429 ___ 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/162509: [re] [panic] Kernel panic may be related to if_re.c (realtek 8168 )
Synopsis: [re] [panic] Kernel panic may be related to if_re.c (realtek 8168 ) State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Wed Apr 25 04:33:24 UTC 2012 State-Changed-Why: There had been a lot of change since 8.1-RELEASE. Could you reproduce this on 8.3-RELEASE? If yes, please show me full back trace information on 8.3-RELEASE. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Wed Apr 25 04:33:24 UTC 2012 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=162509 ___ 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: Realtek 8111F
On Tue, Apr 24, 2012 at 02:35:18PM +0200, Karl Stenlund wrote: > I installed freebsd 9.0_amd64 and it can't find my network. i tried to add > "if_re_load="YES"" But it didn't help. > Is the Realtek 8111F not suported by freebsd yet? > Motherboard: ASUS P8H77-I Support for RTL8168/8111F was added after releasing 9.0-RELEASE. Use 8.3-RELEASE or latest stable. Alternatively download the following files from HEAD and rebuild kernel on 9.0-RELEASE. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rl.c http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rlreg.h ___ 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"
