[Bug 211962] bxe driver queue soft hangs and flooding tx_soft_errors
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211962 Kubilay Kocak changed: What|Removed |Added Status|New |Open Keywords||needs-qa Flags||mfc-stable9?, ||mfc-stable10?, ||mfc-stable11? --- Comment #3 from Kubilay Kocak --- Thank you Matt. Can you make those committers aware of this issue if you haven't already so they can assign it to themselves and coordinate it through MFC's and release engineering (if it applies to 11.0-RELEASE) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 128030] [ipsec] Enable IPSec in GENERIC kernel configuration
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=128030 geezabiscu...@hotmail.com changed: What|Removed |Added CC||geezabiscu...@hotmail.com --- Comment #20 from geezabiscu...@hotmail.com --- I'm not sure if this is would require a separate request but I'd like to see IPSEC_NAT_T enabled in the GENERIC kernel also. I use my laptop as a mobile IPSEC client and have to deal with connecting through natted IPs. Currently I need to run a custom kernel just to add IPSEC and IPSEC_NAT_T support and it makes keeping my system up to date somewhat cumbersome. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 128030] [ipsec] Enable IPSec in GENERIC kernel configuration
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=128030 Kubilay Kocak changed: What|Removed |Added Flags||mfc-stable11? Status|Open|In Progress --- Comment #21 from Kubilay Kocak --- (In reply to geezabiscuit2 from comment #20) This issue has already been committed to head and is pending MFC (see comment 13, comment 14, comment 16) I'd suggest create a separate issue with a similar summary (replacing IPSec with IPSEC_NAT_T of course) and add this issue's URL to the new issues "See Also:" field -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 128030] [ipsec] Enable IPSec in GENERIC kernel configuration
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=128030 k...@denninger.net changed: What|Removed |Added CC||k...@denninger.net --- Comment #22 from k...@denninger.net --- (In reply to geezabiscuit2 from comment #20) While we're on the topic... options IPSEC_FILTERTUNNEL ought to be in GENERIC as well and, arguably device enc StrongSwan currently requires (even in 11.x) a custom kernel because these two entries are not in GENERIC. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 128030] [ipsec] Enable IPSec in GENERIC kernel configuration
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=128030 --- Comment #23 from Sydney Meyer --- +1 for IPSEC_NAT_T in GENERIC. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: svn commit: r304313 - head/sys/net
On 17 August 2016 at 13:21, Andrey V. Elsukov wrote:
> Author: ae
> Date: Wed Aug 17 20:21:33 2016
> New Revision: 304313
> URL: https://svnweb.freebsd.org/changeset/base/304313
>
> Log:
> Teach netisr_get_cpuid() to limit a given value to supported by netisr.
> Use netisr_get_cpuid() in netisr_select_cpuid() to limit cpuid value
> returned by protocol to be sure that it is not greather than nws_count.
>
> PR: 211836
> Reviewed by: adrian
> MFC after:3 days
>
> Modified:
> head/sys/net/if_epair.c
> head/sys/net/netisr.c
>
> Modified: head/sys/net/if_epair.c
> ==
> --- head/sys/net/if_epair.c Wed Aug 17 19:43:45 2016(r304312)
> +++ head/sys/net/if_epair.c Wed Aug 17 20:21:33 2016(r304313)
> @@ -807,9 +807,9 @@ epair_clone_create(struct if_clone *ifc,
> * cache locality but we can at least allow parallelism.
> */
> sca->cpuid =
> - netisr_get_cpuid(sca->ifp->if_index % netisr_get_cpucount());
> + netisr_get_cpuid(sca->ifp->if_index);
> scb->cpuid =
> - netisr_get_cpuid(scb->ifp->if_index % netisr_get_cpucount());
> + netisr_get_cpuid(scb->ifp->if_index);
>
> /* Initialise pseudo media types. */
> ifmedia_init(&sca->media, 0, epair_media_change, epair_media_status);
>
> Modified: head/sys/net/netisr.c
> ==
> --- head/sys/net/netisr.c Wed Aug 17 19:43:45 2016(r304312)
> +++ head/sys/net/netisr.c Wed Aug 17 20:21:33 2016(r304313)
> @@ -272,10 +272,7 @@ u_int
> netisr_get_cpuid(u_int cpunumber)
> {
>
> - KASSERT(cpunumber < nws_count, ("%s: %u > %u", __func__, cpunumber,
> - nws_count));
> -
> - return (nws_array[cpunumber]);
> + return (nws_array[cpunumber % nws_count]);
> }
>
> /*
> @@ -810,10 +807,12 @@ netisr_select_cpuid(struct netisr_proto
> * dispatch. In the queued case, fall back on the SOURCE
> * policy.
> */
> - if (*cpuidp != NETISR_CPUID_NONE)
> + if (*cpuidp != NETISR_CPUID_NONE) {
> + *cpuidp = netisr_get_cpuid(*cpuidp);
> return (m);
> + }
> if (dispatch_policy == NETISR_DISPATCH_HYBRID) {
> - *cpuidp = curcpu;
> + *cpuidp = netisr_get_cpuid(curcpu);
> return (m);
> }
> policy = NETISR_POLICY_SOURCE;
>
I wonder if the right-er thing to do here is to allow the cpuid to be
whatever it needs to be, but limit the cpuid lookups when it resolves
to a netisr array.
that'd mean the hybrid model would still return the current CPU up to
the max CPU id, but anything trying to queue into a netisr would not
overflow the netisr queue count.
Thoughts?
-a
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 128030] [ipsec] Enable IPSec in GENERIC kernel configuration
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=128030 --- Comment #24 from Darryn Nicol --- I've created a new request to add IPSEC_NAT_T: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212018 -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 128030] [ipsec] Enable IPSec in GENERIC kernel configuration
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=128030 Bjoern A. Zeeb changed: What|Removed |Added CC||b...@freebsd.org --- Comment #25 from Bjoern A. Zeeb --- (In reply to karl from comment #22) The kernel option IPSEC_FILTERTUNNEL should be removed ... as indicated in commit .. uhm .. https://svnweb.freebsd.org/base?view=revision&revision=192648 ; my bad; should have done that 6 years ago ... please use the loader tunable; no need to compile a different kernel for this anymore. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 128030] [ipsec] Enable IPSec in GENERIC kernel configuration
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=128030 --- Comment #26 from Bjoern A. Zeeb --- (In reply to Bjoern A. Zeeb from comment #25) Whoops. make that a sysctl (he who can read his own commit messages ...) so you can change it at runtime; even better; no need to reboot or compile a kernel ;-) -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: iwn(4) association issues in 11-Stable (and maybe RC)
Hi, There have been some changes to the scan code and iwn scan timeout code. Andriy may have some ideas. Thanks! A On Aug 19, 2016 3:48 PM, "Kevin Oberman" wrote: > Lately I have had serious issues with my system successfully associating. > These were not present with 10.3. > > > uname -a > FreeBSD rogue 11.0-BETA4 FreeBSD 11.0-BETA4 #1 r303806: Sat Aug 6 18:50:50 > PDT 2016 root@rogue:/usr/obj/usr/src/sys/GENERIC.4BSD amd64 > > iwn0@pci0:3:0:0:class=0x028000 card=0x13118086 chip=0x00858086 > rev=0x34 > hdr=0x00 > cap 01[c8] = powerspec 3 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint max data 128(128) FLR RO NS > link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) > ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected > ecap 0003[140] = Serial 1 a088b4c6ad28 > > Once associated, it works fine, but a dropped association is often not > re-established and the network fails to come up at boot time. Kernel is > GENERIC except the 4BSD scheduler. > > I've been using a mobile hotspot this week during travels and it has become > a real pain. With lot of patience and many "netif restart wlan0" > operations, it will come up, but it can be painful. Here is what I see in > messages: > Aug 19 00:13:52 rogue kernel: wlan0: Ethernet address: a0:88:b4:c6:ad:28 > Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 > Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP > Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN > Aug 19 00:13:52 rogue kernel: iwn0: scan timeout > Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 > Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP > Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN > Aug 19 00:13:52 rogue kernel: iwn0: scan timeout > Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 > Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP > Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN > Aug 19 00:13:52 rogue kernel: iwn0: scan timeout > Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 > Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP > Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN > Aug 19 00:13:52 rogue kernel: iwn0: scan timeout > Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 > Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP > Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN > Aug 19 00:13:52 rogue kernel: iwn0: scan timeout > Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 > Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP > Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN > Aug 19 00:13:52 rogue kernel: iwn0: scan timeout > Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 > Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP > Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN > Aug 19 00:13:52 rogue kernel: iwn0: scan timeout > Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 > Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP > Aug 19 00:13:52 rogue kernel: ipfw2 (+ipv6) initialized, divert loadable, > nat loadable, default to deny, logging disabled > Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN > Aug 19 00:13:52 rogue kernel: iwn0: scan timeout > Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 > Aug 19 00:14:17 rogue dhclient[362]: send_packet: Network is down > Aug 19 00:14:37 rogue dhclient[362]: send_packet: Network is down > Aug 19 00:14:39 rogue wpa_supplicant[350]: wlan0: CTRL-EVENT-TERMINATING > Aug 19 00:14:39 rogue dhclient[362]: connection closed > Aug 19 00:14:39 rogue dhclient[362]: exiting. > Aug 19 00:14:39 rogue rtsold[873]: interface > wlan0 removed > Aug 19 00:14:39 rogue kernel: wlan0: Ethernet address: a0:88:b4:c6:ad:28 > Aug 19 00:14:39 rogue wpa_supplicant[1621]: Successfully initialized > wpa_supplicant > Aug 19 00:14:39 rogue wpa_supplicant[1633]: Successfully initialized > wpa_supplicant > Aug 19 00:14:39 rogue root: /etc/rc.d/wpa_supplicant: WARNING: failed to > start wpa_supplicant > Aug 19 00:14:39 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 > Aug 19 00:14:39 rogue wpa_supplicant[1634]: ioctl[SIOCS80211, op=103, > val=0, arg_len=128]: Operation now in progress > Aug 19 00:14:39 rogue wpa_supplicant[1634]: wlan0: CTRL-EVENT-SCAN-FAILED > ret=-1 retry=1 > Aug 19 00:14:40 rogue wpa_supplicant[1634]: ioctl[SIOCS80211, op=103, > val=0, arg_len=128]: Operation now in progress > Aug 19 00:14:40 rogue wpa_supplicant[1634]: wlan0: CTRL-EVENT-SCAN-FAILED > ret=-1 retry=1 > Aug 19 00:14:41 rogue wpa_supplicant[1634]: ioctl[SIOCS80211, op=103, > val=0, ar
Re: iwn(4) association issues in 11-Stable (and maybe RC)
On Aug 20, 2016 6:29 PM, "Adrian Chadd" wrote: > > Hi, > > There have been some changes to the scan code and iwn scan timeout code. Andriy may have some ideas. > > Thanks! > > A One more note. There are multiple "link up" messages in the log. The LED never stopped the flashing which indicates that it is not associated. If I did "ifconfig wlan0 list aps", my hot spot was listed, but a simple "ifconfig wlan0" never showed an association. Usually a few "netif restart"s will get it to work, but sometimes it seems hopeless. It seems worse when my phone is the hot spot than with my home router. > > > On Aug 19, 2016 3:48 PM, "Kevin Oberman" wrote: >> >> Lately I have had serious issues with my system successfully associating. >> These were not present with 10.3. >> >> > uname -a >> FreeBSD rogue 11.0-BETA4 FreeBSD 11.0-BETA4 #1 r303806: Sat Aug 6 18:50:50 >> PDT 2016 root@rogue:/usr/obj/usr/src/sys/GENERIC.4BSD amd64 >> >> iwn0@pci0:3:0:0:class=0x028000 card=0x13118086 chip=0x00858086 rev=0x34 >> hdr=0x00 >> cap 01[c8] = powerspec 3 supports D0 D3 current D0 >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message >> cap 10[e0] = PCI-Express 1 endpoint max data 128(128) FLR RO NS >> link x1(x1) speed 2.5(2.5) ASPM L1(L0s/L1) >> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected >> ecap 0003[140] = Serial 1 a088b4c6ad28 >> >> Once associated, it works fine, but a dropped association is often not >> re-established and the network fails to come up at boot time. Kernel is >> GENERIC except the 4BSD scheduler. >> >> I've been using a mobile hotspot this week during travels and it has become >> a real pain. With lot of patience and many "netif restart wlan0" >> operations, it will come up, but it can be painful. Here is what I see in >> messages: >> Aug 19 00:13:52 rogue kernel: wlan0: Ethernet address: a0:88:b4:c6:ad:28 >> Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 >> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP >> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN >> Aug 19 00:13:52 rogue kernel: iwn0: scan timeout >> Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 >> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP >> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN >> Aug 19 00:13:52 rogue kernel: iwn0: scan timeout >> Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 >> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP >> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN >> Aug 19 00:13:52 rogue kernel: iwn0: scan timeout >> Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 >> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP >> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN >> Aug 19 00:13:52 rogue kernel: iwn0: scan timeout >> Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 >> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP >> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN >> Aug 19 00:13:52 rogue kernel: iwn0: scan timeout >> Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 >> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP >> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN >> Aug 19 00:13:52 rogue kernel: iwn0: scan timeout >> Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 >> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP >> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN >> Aug 19 00:13:52 rogue kernel: iwn0: scan timeout >> Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 >> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to UP >> Aug 19 00:13:52 rogue kernel: ipfw2 (+ipv6) initialized, divert loadable, >> nat loadable, default to deny, logging disabled >> Aug 19 00:13:52 rogue kernel: wlan0: link state changed to DOWN >> Aug 19 00:13:52 rogue kernel: iwn0: scan timeout >> Aug 19 00:13:52 rogue kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601 >> Aug 19 00:14:17 rogue dhclient[362]: send_packet: Network is down >> Aug 19 00:14:37 rogue dhclient[362]: send_packet: Network is down >> Aug 19 00:14:39 rogue wpa_supplicant[350]: wlan0: CTRL-EVENT-TERMINATING >> Aug 19 00:14:39 rogue dhclient[362]: connection closed >> Aug 19 00:14:39 rogue dhclient[362]: exiting. >> Aug 19 00:14:39 rogue rtsold[873]: interface >> wlan0 removed >> Aug 19 00:14:39 rogue kernel: wlan0: Ethernet address: a0:88:b4:c6:ad:28 >> Aug 19 00:14:39 rogue wpa_supplicant[1621]: Successfully initialized >> wpa_supplicant >> Aug 19 00:14:39 rogue wpa_supplicant[1633]: Successfully initialized >> wpa_supplicant >> Aug 19 00:14:39 rogue root: /etc/rc.d/wpa_supplicant: WARNING: failed to >> start wpa_supplicant >> Aug 19 00:14:39 rogue kerne
Re: iwn(4) association issues in 11-Stable (and maybe RC)
On 20 August 2016 at 19:02, Kevin Oberman wrote: > On Aug 20, 2016 6:29 PM, "Adrian Chadd" wrote: >> >> Hi, >> >> There have been some changes to the scan code and iwn scan timeout code. >> Andriy may have some ideas. >> >> Thanks! >> >> A > > One more note. There are multiple "link up" messages in the log. The LED > never stopped the flashing which indicates that it is not associated. If I > did "ifconfig wlan0 list aps", my hot spot was listed, but a simple > "ifconfig wlan0" never showed an association. Usually a few "netif restart"s > will get it to work, but sometimes it seems hopeless. It seems worse when my > phone is the hot spot than with my home router. I've not seen this happen with any of the iwn hardware that I have, but wifi is odd like that. it looks like wpa_supplicant is started twice. Is that happening? That (sigh) still may be making things unhappy. -adrian ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 212018] [ipsec] [request] Enable IPSEC_NAT_T in GENERIC kernel configuration
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212018 Mark Linimon changed: What|Removed |Added Summary|[ipsec] Enable IPSEC_NAT_T |[ipsec] [request] Enable |in GENERIC kernel |IPSEC_NAT_T in GENERIC |configuration |kernel configuration Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 212018] Enable IPSEC_NAT_T in GENERIC kernel configuration
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212018 Kubilay Kocak changed: What|Removed |Added Keywords||feature, needs-patch Flags||mfc-stable10?, ||mfc-stable11? Summary|[ipsec] [request] Enable|Enable IPSEC_NAT_T in |IPSEC_NAT_T in GENERIC |GENERIC kernel |kernel configuration|configuration Status|New |Open -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
