Re: kern/149306: [alc] Doesn't work Atheros AR8131 PCIe Gigabit Ethernet
Hi it;s not working because of you have to apply ms kb2010 08-9 patch. On Thu, Aug 5, 2010 at 7:20 PM, Troye Johnson wrote: > The following reply was made to PR kern/149306; it has been noted by GNATS. > > From: Troye Johnson > To: bug-follo...@freebsd.org, aksen...@gmail.com > Cc: > Subject: Re: kern/149306: [alc] Doesn't work Atheros AR8131 PCIe Gigabit > Ethernet > Date: Thu, 5 Aug 2010 17:16:07 + > > --000e0cd51986b1efd9048d16b405 > Content-Type: text/plain; charset=ISO-8859-1 > > I think this is misfiled as I have this chip and it is detected properly and > and I can transfer files over the link in 100mbit. Misfiled/erroneous PR? > > --000e0cd51986b1efd9048d16b405 > Content-Type: text/html; charset=ISO-8859-1 > > I think this is misfiled as I have this chip and it is detected properly and > and I can transfer files over the link in 100mbit. Misfiled/erroneous PR? > > --000e0cd51986b1efd9048d16b405-- > ___ > 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" > ___ 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: 8.1-RELEASE em watchdog timeout broken?
Our company had to deal with the same problem We going to help you for 10k usd. On Wed, Aug 4, 2010 at 7:19 AM, Jack Vogel wrote: > The watchdog is working in all the internal testing that we've done, if > there's > some corner case here then I need more info to reproduce it. I'm confused > about what's what, which machine is your desktop and what is the 'other' > system? > > For instance, we had a loud complaint about the watchdog here a while back, > and it turned out the user had increased the system HZ value to something > really high... I've yet to see something that indicates the code is broken. > > If it involves Windows then it goes outside the parameters of my testing so > who knows :) > > Jack > > > On Tue, Aug 3, 2010 at 7:02 PM, Scott Johnson wrote: > >> Under 8.0-RELEASE I would get warnings from em(4) in /var/log/messages >> about >> >> "watchdog timeouts" on em0 whenever my desktop PC connected to em0 was >> powered >> off. This was fine, except for the annoying warnings. >> >> Under 8.1-RELEASE I no longer get the warnings, and any time my desktop is >> powered off, when I turn it back on, it has no connectivity. The interface >> is >> dead until I log into the console and run: >> # ifconfig em0 down up >> >> The em(4) driver has changed a lot since 8.0-RELEASE. It seems this >> watchdog >> timeout is no longer working. >> >> The board is a Supermicro X7SPA-H with Intel 82574L GbE. >> >> Any ideas for debugging? >> ___ >> 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" >> > ___ > 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" > ___ 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: net.inet.tcp.slowstart_flightsize in 8-STABLE
On 13.07.2010 16:01, Maxim Dounin wrote: Hello! On Wed, May 12, 2010 at 04:47:02PM +0400, Igor Sysoev wrote: It seems that net.inet.tcp.slowstart_flightsize does not work in 8-STABLE. For a long time I used slowstart_flightsize=2 on FreeBSD 4, 6, and 7 hosts. However, FreeBSD-8 always starts with the single packet. I saw this on different versions of 8-STABLE since 8 Oct 2009 till 04 Apr 2010. Finally I had some time to look into it (sorry for long delay). 1. Slow start isn't used on recent FreeBSD versions for initial snd_cwnd calculations as long as you have rfc3390 support switched on (default since Jan 06 23:29:46 2004, at least in 7.*). It effectively sets initial snd_cwnd to 3*MSS on common networks and shouldn't cause any problems. Slowstart_flightsize only affects connection restarts. 2. Due to bug in syncache code (patch below) all accepted connections has their snd_cwnd reset to 1*MSS (since r171639, 7.0+ AFAIR). 3. Support for rfc3465 introduced in r187289 uncovered (2) as ACK to SYN/ACK no longer causes snd_cwnd increase by MSS (actually, this increase shouldn't happen as it's explicitly forbidden by rfc 3390, but it's another issue). Snd_cwnd remains really small (1*MSS + 1) and this causes really bad interaction with delayed acks on other side. As a workaround to delayed acks interaction problems you may disable rfc3465 by setting net.inet.tcp.rfc3465 to 0. Correct fix would be to apply the patch below. To Andre Oppermann: could you please take a look at the patch and commit it if found appropriate? I've committed your fix with svn r210666. In a few days I will MFC it back to the stable branches. Thanks for reporting the bug and a patch for it. -- Andre # HG changeset patch # User Maxim Dounin # Date 1279028684 -14400 # Node ID 93699203f408fa8e22c971769bde9c26bd14d410 # Parent e2cf8c51a6294a0d09d5628d96c6ab3ab626957e Fix cwnd resetting problem introduced in r171639. Sc_rxmits counts timer engagements, not actual retransmits, and value 1 corresponds to no retransmits. Revert check to correct one as present before r171639. diff --git a/netinet/tcp_syncache.c b/netinet/tcp_syncache.c --- a/netinet/tcp_syncache.c +++ b/netinet/tcp_syncache.c @@ -804,8 +804,10 @@ syncache_socket(struct syncache *sc, str /* * If the SYN,ACK was retransmitted, reset cwnd to 1 segment. +* Note that sc_rxmits counts timer engagements, not actual +* retransmits. */ - if (sc->sc_rxmits) + if (sc->sc_rxmits> 1) tp->snd_cwnd = tp->t_maxseg; tcp_timer_activate(tp, TT_KEEP, tcp_keepinit); Maxim Dounin ___ 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" ___ 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: net.inet.tcp.slowstart_flightsize in 8-STABLE
Sorry but this is not a bug. You set bad sysctl flags. We won't add it to our database and this is the final decison. Regards, Freebsd Team On Fri, Aug 6, 2010 at 10:56 AM, Andre Oppermann wrote: > On 13.07.2010 16:01, Maxim Dounin wrote: >> >> Hello! >> >> On Wed, May 12, 2010 at 04:47:02PM +0400, Igor Sysoev wrote: >> >>> It seems that net.inet.tcp.slowstart_flightsize does not work in >>> 8-STABLE. >>> For a long time I used slowstart_flightsize=2 on FreeBSD 4, 6, and 7 >>> hosts. >>> However, FreeBSD-8 always starts with the single packet. >>> I saw this on different versions of 8-STABLE since 8 Oct 2009 till >>> 04 Apr 2010. >> >> Finally I had some time to look into it (sorry for long delay). >> >> 1. Slow start isn't used on recent FreeBSD versions for initial snd_cwnd >> calculations as long as you have rfc3390 support switched on (default >> since >> Jan 06 23:29:46 2004, at least in 7.*). It effectively sets initial >> snd_cwnd to 3*MSS on common networks and shouldn't cause any problems. >> Slowstart_flightsize only affects connection restarts. >> >> 2. Due to bug in syncache code (patch below) all accepted connections has >> their snd_cwnd reset to 1*MSS (since r171639, 7.0+ AFAIR). >> >> 3. Support for rfc3465 introduced in r187289 uncovered (2) as >> ACK to SYN/ACK no longer causes snd_cwnd increase by MSS (actually, this >> increase shouldn't happen as it's explicitly forbidden by rfc 3390, but >> it's another issue). Snd_cwnd remains really small (1*MSS + 1) and this >> causes really bad interaction with delayed acks on other side. >> >> As a workaround to delayed acks interaction problems you may disable >> rfc3465 by setting net.inet.tcp.rfc3465 to 0. Correct fix would be to >> apply >> the patch below. >> >> To Andre Oppermann: could you please take a look at the patch and >> commit it if found appropriate? > > I've committed your fix with svn r210666. In a few days I will MFC it back > to the stable branches. Thanks for reporting the bug and a patch for it. > > -- > Andre > >> # HG changeset patch >> # User Maxim Dounin >> # Date 1279028684 -14400 >> # Node ID 93699203f408fa8e22c971769bde9c26bd14d410 >> # Parent e2cf8c51a6294a0d09d5628d96c6ab3ab626957e >> Fix cwnd resetting problem introduced in r171639. >> >> Sc_rxmits counts timer engagements, not actual retransmits, and value 1 >> corresponds to no retransmits. Revert check to correct one as present >> before r171639. >> >> diff --git a/netinet/tcp_syncache.c b/netinet/tcp_syncache.c >> --- a/netinet/tcp_syncache.c >> +++ b/netinet/tcp_syncache.c >> @@ -804,8 +804,10 @@ syncache_socket(struct syncache *sc, str >> >> /* >> * If the SYN,ACK was retransmitted, reset cwnd to 1 segment. >> + * Note that sc_rxmits counts timer engagements, not actual >> + * retransmits. >> */ >> - if (sc->sc_rxmits) >> + if (sc->sc_rxmits> 1) >> tp->snd_cwnd = tp->t_maxseg; >> tcp_timer_activate(tp, TT_KEEP, tcp_keepinit); >> >> >> Maxim Dounin >> ___ >> 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" >> >> > > ___ > 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" > ___ 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: net.inet.tcp.slowstart_flightsize in 8-STABLE
On 06.08.2010 11:00, Charles Logan wrote: Sorry but this is not a bug. You set bad sysctl flags. Care to explain in more detail? For example which sysctl flag was set wrong? We won't add it to our database and this is the final decison. Which database? Regards, Freebsd Team Which team? What is your @FreeBSD.ORG address? -- Andre On Fri, Aug 6, 2010 at 10:56 AM, Andre Oppermann wrote: On 13.07.2010 16:01, Maxim Dounin wrote: Hello! On Wed, May 12, 2010 at 04:47:02PM +0400, Igor Sysoev wrote: It seems that net.inet.tcp.slowstart_flightsize does not work in 8-STABLE. For a long time I used slowstart_flightsize=2 on FreeBSD 4, 6, and 7 hosts. However, FreeBSD-8 always starts with the single packet. I saw this on different versions of 8-STABLE since 8 Oct 2009 till 04 Apr 2010. Finally I had some time to look into it (sorry for long delay). 1. Slow start isn't used on recent FreeBSD versions for initial snd_cwnd calculations as long as you have rfc3390 support switched on (default since Jan 06 23:29:46 2004, at least in 7.*). It effectively sets initial snd_cwnd to 3*MSS on common networks and shouldn't cause any problems. Slowstart_flightsize only affects connection restarts. 2. Due to bug in syncache code (patch below) all accepted connections has their snd_cwnd reset to 1*MSS (since r171639, 7.0+ AFAIR). 3. Support for rfc3465 introduced in r187289 uncovered (2) as ACK to SYN/ACK no longer causes snd_cwnd increase by MSS (actually, this increase shouldn't happen as it's explicitly forbidden by rfc 3390, but it's another issue). Snd_cwnd remains really small (1*MSS + 1) and this causes really bad interaction with delayed acks on other side. As a workaround to delayed acks interaction problems you may disable rfc3465 by setting net.inet.tcp.rfc3465 to 0. Correct fix would be to apply the patch below. To Andre Oppermann: could you please take a look at the patch and commit it if found appropriate? I've committed your fix with svn r210666. In a few days I will MFC it back to the stable branches. Thanks for reporting the bug and a patch for it. -- Andre # HG changeset patch # User Maxim Dounin # Date 1279028684 -14400 # Node ID 93699203f408fa8e22c971769bde9c26bd14d410 # Parent e2cf8c51a6294a0d09d5628d96c6ab3ab626957e Fix cwnd resetting problem introduced in r171639. Sc_rxmits counts timer engagements, not actual retransmits, and value 1 corresponds to no retransmits. Revert check to correct one as present before r171639. diff --git a/netinet/tcp_syncache.c b/netinet/tcp_syncache.c --- a/netinet/tcp_syncache.c +++ b/netinet/tcp_syncache.c @@ -804,8 +804,10 @@ syncache_socket(struct syncache *sc, str /* * If the SYN,ACK was retransmitted, reset cwnd to 1 segment. +* Note that sc_rxmits counts timer engagements, not actual +* retransmits. */ - if (sc->sc_rxmits) + if (sc->sc_rxmits>1) tp->snd_cwnd = tp->t_maxseg; tcp_timer_activate(tp, TT_KEEP, tcp_keepinit); Maxim Dounin ___ 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" ___ 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" ___ 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" ___ 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: net.inet.tcp.slowstart_flightsize in 8-STABLE
On Fri, Aug 6, 2010 at 11:47 AM, Andre Oppermann wrote: > On 06.08.2010 11:00, Charles Logan wrote: >> >> Sorry but this is not a bug. You set bad sysctl flags. > > Care to explain in more detail? For example which sysctl flag was set > wrong? > >> We won't add it to our database and this is the final decison. > > Which database? > >> Regards, >> Freebsd Team > > Which team? What is your @FreeBSD.ORG address? It's a spambot. -- Good, fast & cheap. Pick any two. ___ 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"
Server sporadically sending unexpected RST to Client
Hello, We have recently upgraded some productions systems to 8.0-p2 from 7.1-p5 and are having some sporadic issues with TCP connections that were not occurring previously. The problem was first noticed while running slapd with clients coming in at various times to make LDAP queries; at various points during the day we would receive the follow message in the slapd log (along with the client complaining because the connection was reset): daemon: accept(7) failed errno=53 (Software caused connection abort) We began digging into slapd, during which we were running tcpdump to catch the traffic between the client and server. After a bit tracing through the dumps, the following pattern emerged during the failure times: Client -> Server [SYN] Server -> Client [SYN, ACK] Client -> Server [ACK] Client -> Server [Request] Server -> Client [RST] Server -> Client [Response] Client -> Server [RST] Between the trace above and the accept error, it prompted the question as to why slapd would be throwing an accept error and still be trying to respond to data? It felt like a double trigger, but slapd doesn't appear to be reusing anything, so our next steps lead us to either something in pf or in the kernel as potentially causing the error. The first step was to remove pf as a variable, so we disabled pf (pfctl -d) and found that the issue continued. Eventually, we turned on net.inet.flowtable.debug and net.inet.tcp.log_debug in order to capture some more data and that lead us to the following error: kernel: TCP: [10.174.80.233]:20949 to [10.174.80.242]:389 tcpflags 0x10; tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage, sending RST The first thought was we were overflowing the listen queue but netstat -sp tcp showed the listen queue overflows count was not increasing and the system itself didn't have that many connections coming in at that time (though there was quite a bit of activity from various clients). We also verified that the CPU and memory usage was within a reasonable range (nothing was being stressed and there was plenty of memory to go around. For the sake of being complete, the server in question is a dual CPU (eight cores total) Intel server with 12GB of memory). All of this prompted us to build a debug version of the kernel with some additional logging and we eventually found that we were ultimately failing in in_pcb.c, in_pcbconnect_setup we got EADDRINUSE returned after the in_pcblookup_hash call. We've also noticed that net.tcp.syncache.count will go to -1 when this failure occurs. Per a similar issue (http://lists.freebsd.org/pipermail/freebsd-net/2010-May/025307.html) we were lead to trying to turn off syncookies by setting net.inet.tcp.syncookies to zero which has lead to the error not reappearing (and syncache.count never goes back to -1), however, the connection failures would still occur (shown from client logs and backed up by tcpdumps that show the same pattern as above). This would seem to indicate that there is a problem with syncache. Additionally, we've also found the following pattern while debugging the kernel for the failed connection (note: syncookies is still disabled at this point): kernel: Entering syncache_add kernel: Entering syncache_expand kernel: TCP: [10.174.50.35]:43667 to [10.174.80.242]:389 tcpflags 0x18; syncache_expand: Just before syncache_socket() kernel: Entering syncache_socket kernel: Entering syncache_expand kernel: TCP: [10.174.50.35]:43667 to [10.174.80.242]:389 tcpflags 0x10; syncache_expand: Spurious ACK, segment rejected (syncookies disabled) The above pattern appears to indicate that the PSH is coming in before the final ACK in the handshake (somehow out of order); however, the tcpdumps clearly show everything is coming across in order. Finally, we've also attempted to test with syncookies=1 and syncookies_only=1, which results in the connection failures (as well as the reappearance of the slapd accept error messages). Does anyone have any thoughts on this issue? # uname -a FreeBSD HA1 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #8: Mon Apr 19 16:31:20 UTC 2010 se...@newcastle.greatbaysoftware.com:/usr/obj/usr/src/sys/KERNEL i386 # sysctl net.inet.tcp.syncache net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: -1 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.bucketlimit: 30 # netstat -Lan | grep 389 tcp4 0/0/128*.389 # netstat -sp tcp tcp: 5596836 packets sent 2431990 data packets (3645983288 bytes) 33 data packets (31121 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 2498873 ack-only packets (48245 delayed) 0 URG only packets
problem with 82599 controller
Hello, the following problem I've faced while working with 82599-controller (ixgbe driver): - During packet capturing, after the number of received packets exceeds all allocated descriptors (ixgbe_rxd * ixgbe_num_queues), the next new incoming packets will be sometimes DMA'ed into the RAM incorrectly. Output from my tcpdump session: % tcpdump -i ix1 ... 15:36:54.970343 IP 10.0.0.2.discard > 12.0.0.160.2200: UDP, length 58 15:36:55.070357 IP 10.0.0.2.discard > 12.0.0.161.2200: UDP, length 58 15:36:55.170373 c7:49:54:a8:00:0c (oui Unknown) > 35:c5:66:d7:df:e8 (oui Unknown), ethertype Unknown (0xd53b), length 100: 0x: 4d98 ed85 7537 3b6b 3b8f 7102 4b1c 2cd4 M...u7;k;.q.K.,. 0x0010: 41a8 2f3d 4faa fc8a a039 0fe2 5960 fad5 A./=O9..Y`.. 0x0020: c8b0 964b b0e0 2213 6aa2 330c ef93 80a9 ...K..".j.3. 0x0030: 6ac8 071b a9bd 0d51 ecca 94ba ac9c 873b j..Q...; 0x0040: a83f aeb0 20f4 cfd9 d1fa 93f3 795c 7d20 .?..y\}. 0x0050: 2993 ). 15:36:55.270388 IP 10.0.0.2.discard > 12.0.0.163.2200: UDP, length 58 ... For packets generating I am using Linux kernel packet generator. The receive- and send-interfaces are connected directly (without any hops in the middle). By the each new generated packet the destination-IP-address will be incremented, so I can proof the correctness of received traffic. This error appears in both -STABLE and -CURRENT I guess it is not a software bug and I would like to check out whether the controller is in order. Are there any test setups for 8259x controllers that I could use ? Thanks, Alex ___ 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 82599 controller
What is the exact PCI ID of your adapter (pciconf -l)? How is it configured, on what kind of hardware, how many queues does it have, etc, etc? Jack On Fri, Aug 6, 2010 at 10:03 AM, Alexander Fiveg wrote: > Hello, > > the following problem I've faced while working with 82599-controller (ixgbe > driver): > > - During packet capturing, after the number of received packets exceeds all > allocated descriptors (ixgbe_rxd * ixgbe_num_queues), the next new incoming > packets will be sometimes DMA'ed into the RAM incorrectly. > > Output from my tcpdump session: > > % tcpdump -i ix1 > ... > 15:36:54.970343 IP 10.0.0.2.discard > 12.0.0.160.2200: UDP, length 58 > 15:36:55.070357 IP 10.0.0.2.discard > 12.0.0.161.2200: UDP, length 58 > 15:36:55.170373 c7:49:54:a8:00:0c (oui Unknown) > 35:c5:66:d7:df:e8 (oui > Unknown), ethertype Unknown (0xd53b), length 100: >0x: 4d98 ed85 7537 3b6b 3b8f 7102 4b1c 2cd4 M...u7;k;.q.K.,. >0x0010: 41a8 2f3d 4faa fc8a a039 0fe2 5960 fad5 A./=O9..Y`.. >0x0020: c8b0 964b b0e0 2213 6aa2 330c ef93 80a9 ...K..".j.3. >0x0030: 6ac8 071b a9bd 0d51 ecca 94ba ac9c 873b j..Q...; >0x0040: a83f aeb0 20f4 cfd9 d1fa 93f3 795c 7d20 .?..y\}. >0x0050: 2993 ). > 15:36:55.270388 IP 10.0.0.2.discard > 12.0.0.163.2200: UDP, length 58 > ... > > For packets generating I am using Linux kernel packet generator. The > receive- > and send-interfaces are connected directly (without any hops in the > middle). > By the each new generated packet the destination-IP-address will be > incremented, so I can proof the correctness of received traffic. This > error > appears in both -STABLE and -CURRENT > > I guess it is not a software bug and I would like to check out whether the > controller is in order. > > Are there any test setups for 8259x controllers that I could use ? > > Thanks, > Alex > ___ > 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" > ___ 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 82599 controller
On Friday 06 August 2010 19:20:58 Jack Vogel wrote: > What is the exact PCI ID of your adapter (pciconf -l)? 0x10fb % sysctl dev.ix.0 ~ dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.2.1 dev.ix.0.%driver: ix dev.ix.0.%location: slot=0 function=0 dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x0003 class=0x02 dev.ix.0.%parent: pci1 dev.ix.0.stats: -1 dev.ix.0.debug: -1 dev.ix.0.flow_control: 3 dev.ix.0.enable_aim: 1 dev.ix.0.rx_processing_limit: 128 % pciconf -l no...@pci0:0:0:0: class=0x058000 card=0x chip=0x005e10de rev=0xa3 hdr=0x00 is...@pci0:0:1:0: class=0x060100 card=0xcb8410de chip=0x005110de rev=0xa3 hdr=0x00 no...@pci0:0:1:1: class=0x0c0500 card=0xcb8410de chip=0x005210de rev=0xa2 hdr=0x00 oh...@pci0:0:2:0: class=0x0c0310 card=0xcb8410de chip=0x005a10de rev=0xa2 hdr=0x00 eh...@pci0:0:2:1: class=0x0c0320 card=0xcb8410de chip=0x005b10de rev=0xa3 hdr=0x00 atap...@pci0:0:6:0: class=0x01018a card=0xcb8410de chip=0x005310de rev=0xf2 hdr=0x00 atap...@pci0:0:7:0: class=0x010485 card=0xcb8410de chip=0x005410de rev=0xf3 hdr=0x00 atap...@pci0:0:8:0: class=0x010485 card=0xcb8410de chip=0x005510de rev=0xf3 hdr=0x00 pc...@pci0:0:9:0: class=0x060401 card=0x chip=0x005c10de rev=0xa2 hdr=0x01 pc...@pci0:0:13:0: class=0x060400 card=0x chip=0x005d10de rev=0xa3 hdr=0x01 pc...@pci0:0:14:0: class=0x060400 card=0x chip=0x005d10de rev=0xa3 hdr=0x01 hos...@pci0:0:24:0: class=0x06 card=0x chip=0x11001022 rev=0x00 hdr=0x00 hos...@pci0:0:24:1: class=0x06 card=0x chip=0x11011022 rev=0x00 hdr=0x00 hos...@pci0:0:24:2: class=0x06 card=0x chip=0x11021022 rev=0x00 hdr=0x00 hos...@pci0:0:24:3: class=0x06 card=0x chip=0x11031022 rev=0x00 hdr=0x00 hos...@pci0:0:25:0: class=0x06 card=0x chip=0x11001022 rev=0x00 hdr=0x00 hos...@pci0:0:25:1: class=0x06 card=0x chip=0x11011022 rev=0x00 hdr=0x00 hos...@pci0:0:25:2: class=0x06 card=0x chip=0x11021022 rev=0x00 hdr=0x00 hos...@pci0:0:25:3: class=0x06 card=0x chip=0x11031022 rev=0x00 hdr=0x00 hos...@pci0:0:26:0: class=0x06 card=0x chip=0x11001022 rev=0x00 hdr=0x00 hos...@pci0:0:26:1: class=0x06 card=0x chip=0x11011022 rev=0x00 hdr=0x00 host...@pci0:0:26:2:class=0x06 card=0x chip=0x11021022 rev=0x00 hdr=0x00 host...@pci0:0:26:3:class=0x06 card=0x chip=0x11031022 rev=0x00 hdr=0x00 host...@pci0:0:27:0:class=0x06 card=0x chip=0x11001022 rev=0x00 hdr=0x00 host...@pci0:0:27:1:class=0x06 card=0x chip=0x11011022 rev=0x00 hdr=0x00 host...@pci0:0:27:2:class=0x06 card=0x chip=0x11021022 rev=0x00 hdr=0x00 host...@pci0:0:27:3:class=0x06 card=0x chip=0x11031022 rev=0x00 hdr=0x00 vgap...@pci0:3:1:0: class=0x03 card=0x80081002 chip=0x47521002 rev=0x27 hdr=0x00 i...@pci0:1:0:0: class=0x02 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 i...@pci0:1:0:1: class=0x02 card=0x00038086 chip=0x10fb8086 rev=0x01 hdr=0x00 pc...@pci0:4:1:0: class=0x060400 card=0x chip=0x74581022 rev=0x12 hdr=0x01 ioap...@pci0:4:1:1: class=0x080010 card=0x74591022 chip=0x74591022 rev=0x12 hdr=0x00 pc...@pci0:4:2:0: class=0x060400 card=0x chip=0x74581022 rev=0x12 hdr=0x01 ioap...@pci0:4:2:1: class=0x080010 card=0x74591022 chip=0x74591022 rev=0x12 hdr=0x00 e...@pci0:5:3:0: class=0x02 card=0x117a15d9 chip=0x10798086 rev=0x03 hdr=0x00 e...@pci0:5:3:1: class=0x02 card=0x117a15d9 chip=0x10798086 rev=0x03 hdr=0x00 % uname -pr 8.1-STABLE i386 > > How is it configured, on what kind of hardware, how many queues does it > have, > etc, etc? 8 x CPUs - 8 x queues But by reducing the number of queues this problem will appear more often, because the descriptors will be more often reused. (It happens only by the reusing of descriptors. The first (desc_num*queue_num) packets are ALWAYS correctly! after kldload ixgbe.ko in /var/log/messages: Aug 6 16:21:52 ringmap-2 kernel: ix0: port 0xac00-0xac1f mem 0xfe78-0xfe7f,0xfe77c000-0xfe77 irq 16 at device 0.0 on pci1 Aug 6 16:21:52 ringmap-2 kernel: ix0: Using MSIX interrupts with 9 vectors Aug 6 16:21:52 ringmap-2 kernel: ix0: [ITHREAD] Aug 6 16:21:52 ringmap-2 last message repeated 8 times Aug 6 16:21:52 ringmap-2 kernel: ix0: Ethernet address: 00:1b:21:5a:67:70 Aug 6 16:21:52 ringmap-2 kernel: ix0: PCI Express Bus: Speed 2.5Gb/s Width x8 Aug 6 16:21:52 ringmap-2 kernel: ix1: port 0xa800-0xa81f mem 0xfe68-0xfe6f,0xfe778000-0xfe77bfff irq 17 at device 0.1 on pci1 Aug 6 16:21:52 ringmap-2 kernel: ix1: Using MSIX interrupts with 9 vectors Aug 6 16:21:52
Re: problem with 82599 controller
Ouch, you're running 32 bit? Can you compare 64 bit and see if that has any effect? Jack On Fri, Aug 6, 2010 at 10:55 AM, Alexander Fiveg wrote: > On Friday 06 August 2010 19:20:58 Jack Vogel wrote: > > What is the exact PCI ID of your adapter (pciconf -l)? > 0x10fb > > % sysctl dev.ix.0 > ~ > dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - > 2.2.1 > dev.ix.0.%driver: ix > dev.ix.0.%location: slot=0 function=0 > dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 > subdevice=0x0003 class=0x02 > dev.ix.0.%parent: pci1 > dev.ix.0.stats: -1 > dev.ix.0.debug: -1 > dev.ix.0.flow_control: 3 > dev.ix.0.enable_aim: 1 > dev.ix.0.rx_processing_limit: 128 > > > % pciconf -l > no...@pci0:0:0:0: class=0x058000 card=0x chip=0x005e10de > rev=0xa3 hdr=0x00 > is...@pci0:0:1:0: class=0x060100 card=0xcb8410de chip=0x005110de > rev=0xa3 hdr=0x00 > no...@pci0:0:1:1: class=0x0c0500 card=0xcb8410de chip=0x005210de > rev=0xa2 hdr=0x00 > oh...@pci0:0:2:0: class=0x0c0310 card=0xcb8410de chip=0x005a10de > rev=0xa2 hdr=0x00 > eh...@pci0:0:2:1: class=0x0c0320 card=0xcb8410de chip=0x005b10de > rev=0xa3 hdr=0x00 > atap...@pci0:0:6:0: class=0x01018a card=0xcb8410de chip=0x005310de > rev=0xf2 hdr=0x00 > atap...@pci0:0:7:0: class=0x010485 card=0xcb8410de chip=0x005410de > rev=0xf3 hdr=0x00 > atap...@pci0:0:8:0: class=0x010485 card=0xcb8410de chip=0x005510de > rev=0xf3 hdr=0x00 > pc...@pci0:0:9:0: class=0x060401 card=0x chip=0x005c10de > rev=0xa2 hdr=0x01 > pc...@pci0:0:13:0: class=0x060400 card=0x chip=0x005d10de > rev=0xa3 hdr=0x01 > pc...@pci0:0:14:0: class=0x060400 card=0x chip=0x005d10de > rev=0xa3 hdr=0x01 > hos...@pci0:0:24:0: class=0x06 card=0x chip=0x11001022 > rev=0x00 hdr=0x00 > hos...@pci0:0:24:1: class=0x06 card=0x chip=0x11011022 > rev=0x00 hdr=0x00 > hos...@pci0:0:24:2: class=0x06 card=0x chip=0x11021022 > rev=0x00 hdr=0x00 > hos...@pci0:0:24:3: class=0x06 card=0x chip=0x11031022 > rev=0x00 hdr=0x00 > hos...@pci0:0:25:0: class=0x06 card=0x chip=0x11001022 > rev=0x00 hdr=0x00 > hos...@pci0:0:25:1: class=0x06 card=0x chip=0x11011022 > rev=0x00 hdr=0x00 > hos...@pci0:0:25:2: class=0x06 card=0x chip=0x11021022 > rev=0x00 hdr=0x00 > hos...@pci0:0:25:3: class=0x06 card=0x chip=0x11031022 > rev=0x00 hdr=0x00 > hos...@pci0:0:26:0: class=0x06 card=0x chip=0x11001022 > rev=0x00 hdr=0x00 > hos...@pci0:0:26:1: class=0x06 card=0x chip=0x11011022 > rev=0x00 hdr=0x00 > host...@pci0:0:26:2:class=0x06 card=0x chip=0x11021022 > rev=0x00 hdr=0x00 > host...@pci0:0:26:3:class=0x06 card=0x chip=0x11031022 > rev=0x00 hdr=0x00 > host...@pci0:0:27:0:class=0x06 card=0x chip=0x11001022 > rev=0x00 hdr=0x00 > host...@pci0:0:27:1:class=0x06 card=0x chip=0x11011022 > rev=0x00 hdr=0x00 > host...@pci0:0:27:2:class=0x06 card=0x chip=0x11021022 > rev=0x00 hdr=0x00 > host...@pci0:0:27:3:class=0x06 card=0x chip=0x11031022 > rev=0x00 hdr=0x00 > vgap...@pci0:3:1:0: class=0x03 card=0x80081002 chip=0x47521002 > rev=0x27 hdr=0x00 > i...@pci0:1:0:0: class=0x02 card=0x00038086 chip=0x10fb8086 rev=0x01 > hdr=0x00 > i...@pci0:1:0:1: class=0x02 card=0x00038086 chip=0x10fb8086 rev=0x01 > hdr=0x00 > pc...@pci0:4:1:0: class=0x060400 card=0x chip=0x74581022 > rev=0x12 hdr=0x01 > ioap...@pci0:4:1:1: class=0x080010 card=0x74591022 chip=0x74591022 > rev=0x12 hdr=0x00 > pc...@pci0:4:2:0: class=0x060400 card=0x chip=0x74581022 > rev=0x12 hdr=0x01 > ioap...@pci0:4:2:1: class=0x080010 card=0x74591022 chip=0x74591022 > rev=0x12 hdr=0x00 > e...@pci0:5:3:0: class=0x02 card=0x117a15d9 chip=0x10798086 rev=0x03 > hdr=0x00 > e...@pci0:5:3:1: class=0x02 card=0x117a15d9 chip=0x10798086 rev=0x03 > hdr=0x00 > > % uname -pr > 8.1-STABLE i386 > > > > > > How is it configured, on what kind of hardware, how many queues does it > > have, > > etc, etc? > 8 x CPUs - 8 x queues > But by reducing the number of queues this problem will appear more often, > because the descriptors will be more often reused. (It happens only by the > reusing of descriptors. The first (desc_num*queue_num) packets are ALWAYS > correctly! > > > after kldload ixgbe.ko in /var/log/messages: > > Aug 6 16:21:52 ringmap-2 kernel: ix0: Network > Driver, Version - 2.2.1> port 0xac00-0xac1f mem > 0xfe78-0xfe7f,0xfe77c000-0xfe77 irq 16 at device 0.0 on pci1 > Aug 6 16:21:52 ringmap-2 kernel: ix0: Using MSIX interrupts with 9 vectors > Aug 6 16:21:52 ringmap-2 kernel: ix0: [ITHREAD] > Aug 6 16:21:52 ringmap-2 last message repeated 8 times > Aug 6 16:21:52 ringmap-2 kernel: ix0: Ethernet address: 00:1b:21:5a:67:70 > Aug 6 16:21:52 ringmap-2 kernel: ix0: PCI Express Bus: Spee
Re: kern/77913: commit references a PR
The following reply was made to PR kern/77913; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/77913: commit references a PR
Date: Fri, 6 Aug 2010 18:57:22 + (UTC)
Author: bschmidt
Date: Fri Aug 6 18:57:09 2010
New Revision: 210949
URL: http://svn.freebsd.org/changeset/base/210949
Log:
MFC r182236,r182238,182250,182251:
- Add recent ELSA additions to wi(4), plus make sure the list matches
the driver for ELSA.
- The APDL-325 is a Wireless LAN pcmcia adapter that sits inside some
Billion Access Points. Fix wi(4) to recognise the adapter.
- Remove opt_wi.h
PR: kern/77913
Submitted by:Daan Vreeken [PA4DAN]
Modified:
stable/7/share/man/man4/wi.4
stable/7/sys/dev/pccard/pccarddevs
stable/7/sys/dev/wi/if_wi_pccard.c
stable/7/sys/modules/wi/Makefile
Directory Properties:
stable/7/share/man/man4/ (props changed)
stable/7/sys/ (props changed)
stable/7/sys/cddl/contrib/opensolaris/ (props changed)
stable/7/sys/contrib/dev/acpica/ (props changed)
stable/7/sys/contrib/pf/ (props changed)
Modified: stable/7/share/man/man4/wi.4
==
--- stable/7/share/man/man4/wi.4 Fri Aug 6 18:55:49 2010
(r210948)
+++ stable/7/share/man/man4/wi.4 Fri Aug 6 18:57:09 2010
(r210949)
@@ -189,6 +189,9 @@ Dlink DWL650 Prism-2.5 PCMCIA
ELECOM a...@hawk/LD-WL11/PCC PCMCIA
ELSA MC-11PCMCIA
ELSA XI300Prism-IIPCMCIA
+ELSA XI325Prism-2.5 PCMCIA
+ELSA APDL325 Prism-2.5 PCMCIA
+ELSA XI330Prism-3 PCMCIA
ELSA XI800Prism-IICF
EMTAC A2424i Prism-IIPCMCIA
Ericsson Wireless LAN CARD C11Spectrum24 PCMCIA
Modified: stable/7/sys/dev/pccard/pccarddevs
==
--- stable/7/sys/dev/pccard/pccarddevs Fri Aug 6 18:55:49 2010
(r210948)
+++ stable/7/sys/dev/pccard/pccarddevs Fri Aug 6 18:57:09 2010
(r210949)
@@ -320,6 +320,7 @@ product ELSA MC2_IEEE 0x0001 AirLancer
product ELSA XI300_IEEE 0x0002 XI300 Wireless LAN
product ELSA XI800_IEEE 0x0004 XI800 CF Wireless LAN
product ELSA XI325_IEEE 0x0005 XI325 Wireless LAN
+product ELSA APDL325_IEEE 0x0006 ADPL325 Wireless LAN
product ELSA XI330_IEEE 0x0010 XI330 Wireless LAN
product ELSA WIFI_FLASH 0x0101 802.11b plus 128MB Flash
Modified: stable/7/sys/dev/wi/if_wi_pccard.c
==
--- stable/7/sys/dev/wi/if_wi_pccard.c Fri Aug 6 18:55:49 2010
(r210948)
+++ stable/7/sys/dev/wi/if_wi_pccard.c Fri Aug 6 18:57:09 2010
(r210949)
@@ -41,8 +41,6 @@
#include
__FBSDID("$FreeBSD$");
-#include "opt_wi.h"
-
#include
#include
#include
@@ -126,6 +124,7 @@ static const struct pccard_product wi_pc
PCMCIA_CARD(DLINK, DWL650H),
PCMCIA_CARD(ELSA, XI300_IEEE),
PCMCIA_CARD(ELSA, XI325_IEEE),
+ PCMCIA_CARD(ELSA, APDL325_IEEE),
PCMCIA_CARD(ELSA, XI330_IEEE),
PCMCIA_CARD(ELSA, XI800_IEEE),
PCMCIA_CARD(ELSA, WIFI_FLASH),
Modified: stable/7/sys/modules/wi/Makefile
==
--- stable/7/sys/modules/wi/Makefile Fri Aug 6 18:55:49 2010
(r210948)
+++ stable/7/sys/modules/wi/Makefile Fri Aug 6 18:57:09 2010
(r210949)
@@ -3,12 +3,7 @@
.PATH: ${.CURDIR}/../../dev/wi
KMOD= if_wi
-SRCS= opt_wi.h if_wi.c if_wi_pccard.c if_wi_pci.c \
+SRCS= if_wi.c if_wi_pccard.c if_wi_pci.c \
card_if.h device_if.h bus_if.h pci_if.h pccarddevs.h
-.if !defined(KERNBUILDDIR)
-opt_wi.h:
- echo "#define WI_SYMBOL_FIRMWARE 1" > ${.TARGET}
-.endif
-
.include
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
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/77913: [wi] [patch] Add the APDL-325 WLAN pccard to wi(4)
Synopsis: [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) State-Changed-From-To: patched->closed State-Changed-By: bschmidt State-Changed-When: Fri Aug 6 19:13:24 UTC 2010 State-Changed-Why: Patch is included head, stable/8 and stable/7, thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=77913 ___ 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"
[ath] IBM 802.11B B/G 39T0073 card doesn't work in 8-STABLE but worked in 7-STABLE
I upgraded my Thinkpad from 7-STABLE to 8-STABLE a few weeks ago and now my wireless card no longer works. It is recognized, but appears to be somewhat brain dead. # ifconfig ath0 ath0: flags=8802 metric 0 mtu 2290 ether 00:16:ce:00:ac:a7 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier # ifconfig ath0 up # ifconfig ath0 ath0: flags=8843 metric 0 mtu 2290 ether 00:16:ce:00:ac:a7 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier # ifconfig ath0 scan ifconfig: unable to get scan results # ifconfig ath0 list caps ifconfig: unable to get device capabilities: Invalid argument I turned on the ath and ath_hal kernel debug options and this is what shows up at boot: ath0: mem 0xc020-0xc020 irq 9 at device 2.0 on pci2 ath0: [ITHREAD] ar5212Attach: sc 0xc420c000 st 0x1 sh 0xe4553000 ar5212SetPowerMode: AWAKE -> AWAKE (set chip ) ar5212SetPowerMode: AWAKE -> AWAKE (set chip ) ar5212SetPowerMode: AWAKE -> AWAKE (set chip ) EEPROM protect 0x0 enableAniMIBCounters: Enable mib counters: OfdmPhyErrBase 0xbffe0c cckPhyErrBase 0xbfff38 ar5212Attach: return getchannels: cc 0 regDmn 0xf0 mode 0xff ecm getregstate: EEPROM cc 0 rd 0x10 getregstate: EEPROM rd 0x64 getchannels: !avail mode 0x182c (0x2) flags 0x2150 getchannels: !avail mode 0x182c (0x1) flags 0x140 getchannels: !avail mode 0x182c (0x40) flags 0x150 getchannels: !avail mode 0x182c (0x400) flags 0x8140 getchannels: !avail mode 0x182c (0x200) flags 0x4140 getchannels: !avail mode 0x182c (0x8000) flags 0x10480 getchannels: !avail mode 0x182c (0x2) flags 0x20480 getchannels: !avail mode 0x182c (0x4) flags 0x40480 getchannels: !avail mode 0x182c (0x1) flags 0x10140 getchannels: !avail mode 0x182c (0x8) flags 0x20140 getchannels: !avail mode 0x182c (0x10) flags 0x40140 assignPrivateChannels: private[ 0] 2412/0xa0 -> channel 2412 assignPrivateChannels: private[ 1] 2417/0xa0 -> channel 2417 assignPrivateChannels: private[ 2] 2422/0xa0 -> channel 2422 assignPrivateChannels: private[ 3] 2427/0xa0 -> channel 2427 assignPrivateChannels: private[ 4] 2432/0xa0 -> channel 2432 assignPrivateChannels: private[ 5] 2437/0xa0 -> channel 2437 assignPrivateChannels: private[ 6] 2442/0xa0 -> channel 2442 assignPrivateChannels: private[ 7] 2447/0xa0 -> channel 2447 assignPrivateChannels: private[ 8] 2452/0xa0 -> channel 2452 assignPrivateChannels: private[ 9] 2457/0xa0 -> channel 2457 assignPrivateChannels: private[ 10] 2462/0xa0 -> channel 2462 assignPrivateChannels: 23 public, 11 private channels ath_hal_init_channels: cc 0 ath_getchannels: eeprom rd 100 cc 0 (mapped rd 100 cc 0) location I ecm ar5212GetRateTable: invalid mode 0x1 ar5212GetRateTable: invalid mode 0x8000 ath_descdma_setup: rx DMA: 40 buffers 1 desc/buf ath_descdma_setup: rx DMA map: 0xe4563000 (3840) -> 0x111c000 (3840) ath_descdma_setup: tx DMA: 200 buffers 10 desc/buf ath_descdma_setup: tx DMA map: 0xe45c (192000) -> 0x118 (192000) ath_descdma_setup: beacon DMA: 4 buffers 1 desc/buf ath_descdma_setup: beacon DMA map: 0xe45f (384) -> 0x11af000 (384) ar5212SetupTxQueue: queue 9 ar5212SetupTxQueue: queue 8 ar5212SetupTxQueue: queue 0 ar5212SetupTxQueue: queue 1 ar5212SetupTxQueue: queue 2 ar5212SetupTxQueue: queue 3 ath0: AR5212 mac 5.9 RF2112 phy 4.3 Any thoughts on what's going wrong and how to fix it? ___ 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: [ath] IBM 802.11B B/G 39T0073 card doesn't work in 8-STABLE but worked in 7-STABLE
At 03:59 PM 8/6/2010, Don Lewis wrote: # ifconfig ath0 up # ifconfig ath0 ath0: flags=8843 metric 0 mtu 2290 ether 00:16:ce:00:ac:a7 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier # ifconfig ath0 scan Hi, I got caught in the same error. The wireless stuff in RELENG_8 is a bit different. You need to create a wlan interface on top of the ath driver. Take a look at wlan(4) ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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"
Watchdog resets on 82575
If you have this adapter and have been getting watchdogs you need to pick up the small update I checked into HEAD today. When I added the SR-IOV support for the 82576 adapter I removed a call to set the MAC type in an early routine, thinking it was unnecessary, since a slightly later shared code init does the same thing. I also saw no problem when I did this on the 82576 well, it did have a bad effect that I did not notice, the slightly later call, igb_setup_msix() did not have the mac set and this resulted in the 82575 creating more queues than it is really able to handle. So, bottom line, this is a critical fix for 82575: SVN rev 210968 Cheers, Jack ___ 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: [ath] IBM 802.11B B/G 39T0073 card doesn't work in 8-STABLE but worked in 7-STABLE
On 6 Aug, Mike Tancsa wrote: > At 03:59 PM 8/6/2010, Don Lewis wrote: >># ifconfig ath0 up >># ifconfig ath0 >>ath0: flags=8843 metric 0 mtu 2290 >> ether 00:16:ce:00:ac:a7 >> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >> status: no carrier >># ifconfig ath0 scan > > Hi, > I got caught in the same error. The wireless stuff in > RELENG_8 is a bit different. You need to create a wlan interface on > top of the ath driver. Take a look at wlan(4) Thanks! I didn't expect to have to read /usr/src/UPDATING all the way back to early 2008 ... ___ 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"
