problem with 9k jumbo clusters
Hi All. I have a server with two Intel 10G NIC. OS FreeBSD 10.1-Release amd64. Server works like NFS, samba-server and iSCSI target. Both NICs aggregated into lagg device and set MTU 9014 to them. There are some tuning sysctl.conf: kern.maxfiles=6289601 kern.maxfilesperproc=5660640 kern.maxvnodes=3339565 kern.ipc.nmbclusters=12255588 kern.ipc.nmbjumbop=6127794 kern.ipc.nmbufs=78435780 kern.ipc.maxsockbuf=16777216 kern.ipc.maxsockets=6289600 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.sendspace=65536 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=65536 After some days of working, the errors are appearing: ix1: Interface stopped DISTRIBUTING, possible flapping ix0: Interface stopped DISTRIBUTING, possible flapping ix0: Could not setup receive structures ix1: Could not setup receive structures After that errors the NICs stoped working. netstat -m shows: 32881/33854/66735 mbufs in use (current/cache/total) 16370/8198/24568/12255588 mbuf clusters in use (current/cache/total/max) 16370/4807 mbuf+clusters out of packet secondary zone in use (current/cache) 0/873/873/6127794 4k (page size) jumbo clusters in use (current/cache/total/max) 16383/21517/37900/1815641 9k jumbo clusters in use (current/cache/total/max) 0/0/0/1021298 16k jumbo clusters in use (current/cache/total/max) 188407K/222004K/410411K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/101414306/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 9k jumbo clusters max is too big, but looks like system cannot allocate them. There are huge number of "9k requests for jumbo clusters denied". ifconfig ix down/up don't helped, reboot is needed. Thanks for any help! -- Best regards, Tabolin Yuriy System administrator Speech Technology Center ___ 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: Enabling VIMAGE in GENERIC
On Mon, 1 Dec 2014, George Neville-Neil wrote: On a slight tangent. I ran VIMAGE kernels vs. non VIMAGE kernels for both a VANILLA kernel and a PF kernel (PF on but no rules) as a quick smoke test today. The raw forwarding performance was unchanged between kernels with and without VIMAGE on a 10G based system in the Sentex lab (lion1). I will be doing a bit more work in this area and will then put up some results in my netperf github repo. Was this a CPU-bound or network-bound workload? In general, I'd expect VIMAGE to have a modest overhead for most measurable workloads .. unless you are CPU-bound, in which case per-packet processing overheads might become (potentially) quite visible. They will also be more visible on simpler pipelines and with less cache-rich designs -- e.g., SoCs of various sorts. Doing a bit of CPU-bound networking on a modest ARM core might show off the effects better. Robert ___ 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 9k jumbo clusters
On 04.12.2014 13:50, Yuriy Tabolin wrote: Hi All. I have a server with two Intel 10G NIC. OS FreeBSD 10.1-Release amd64. Server works like NFS, samba-server and iSCSI target. Both NICs aggregated into lagg device and set MTU 9014 to them. There are some tuning sysctl.conf: kern.maxfiles=6289601 kern.maxfilesperproc=5660640 kern.maxvnodes=3339565 kern.ipc.nmbclusters=12255588 kern.ipc.nmbjumbop=6127794 kern.ipc.nmbufs=78435780 kern.ipc.maxsockbuf=16777216 kern.ipc.maxsockets=6289600 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.sendspace=65536 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=65536 After some days of working, the errors are appearing: ix1: Interface stopped DISTRIBUTING, possible flapping ix0: Interface stopped DISTRIBUTING, possible flapping ix0: Could not setup receive structures ix1: Could not setup receive structures Hello. It looks like https://lists.freebsd.org/pipermail/freebsd-net/2014-May/038630.html is relevant here. After that errors the NICs stoped working. netstat -m shows: 32881/33854/66735 mbufs in use (current/cache/total) 16370/8198/24568/12255588 mbuf clusters in use (current/cache/total/max) 16370/4807 mbuf+clusters out of packet secondary zone in use (current/cache) 0/873/873/6127794 4k (page size) jumbo clusters in use (current/cache/total/max) 16383/21517/37900/1815641 9k jumbo clusters in use (current/cache/total/max) 0/0/0/1021298 16k jumbo clusters in use (current/cache/total/max) 188407K/222004K/410411K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/101414306/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 9k jumbo clusters max is too big, but looks like system cannot allocate them. There are huge number of "9k requests for jumbo clusters denied". ifconfig ix down/up don't helped, reboot is needed. Thanks for any help! -- Best regards, Tabolin Yuriy System administrator Speech Technology Center ___ 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: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working
On Wed, Dec 3, 2014 at 12:21 PM, David P. Discher wrote: > Hey Net - > > In probably a poor, cheap choice, I picked up a TP-Link TL-SG2008 Desktop > Smart Switch, which supports LACP/802.3ad. I’m currently running 10.1-STABLE > r274577 on the machine I’m testing with. I’m testing right now with just 1 > port (two ports didn’t work either.). > > Hardware is Supermicro X7DB8. > > > em1: port 0x2020-0x203f mem > 0xd826-0xd827,0xd824-0xd825 irq 19 at device 0.1 on pci6 > > em1@pci0:6:0:1: class=0x02 card=0x109615d9 chip=0x10968086 rev=0x01 > hdr=0x00 > vendor = 'Intel Corporation' > device = '80003ES2LAN Gigabit Ethernet Controller (Copper)' > class = network > subclass = ethernet > > >> ifconfig lagg0 > lagg0: flags=8843 metric 0 mtu 1500 > > options=4219b > ether 00:30:48:35:cc:25 > inet 10.1.10.150 netmask 0xff00 broadcast 10.1.10.255 > nd6 options=29 > media: Ethernet autoselect > status: active > laggproto lacp lagghash l2,l3,l4 > laggport: em1 flags=0<> > > > Setting net.link.lagg.lacp.debug=2, here is the output from the the host > trying to negotiate : > > > em1: lacp_sm_rx_update_default_selected > em1: lacp_sm_rx_update_selected_from_peerinfo > em1: lacp_sm_rx_record_default > em1: lacp_sm_mux: state= 0x1, selected= 0x0, p_sync= 0x0, > p_collecting= 0x0 > em1: lacpdu transmit > actor=(8000,00-30-48-35-CC-25,008B,8000,0002) > actor.state=45 > partner=(,00-00-00-00-00-00,,,) > partner.state=0 > maxdelay=0 > em1: lacp_sm_mux: state= 0x0, selected= 0x2, p_sync= 0x0, > p_collecting= 0x0 > em1: lacp_sm_mux: state= 0x1, selected= 0x2, p_sync= 0x0, > p_collecting= 0x0 > em1: lacp_sm_mux: state= 0x1, selected= 0x2, p_sync= 0x0, > p_collecting= 0x0 > em1: lacpdu transmit > actor=(8000,00-30-48-35-CC-25,008B,8000,0002) > actor.state=4d > partner=(,00-00-00-00-00-00,,,) > partner.state=0 > maxdelay=0 > em1: lacp_sm_mux: state= 0x2, selected= 0x2, p_sync= 0x0, > p_collecting= 0x0 > em1: lacp_sm_mux: state= 0x2, selected= 0x2, p_sync= 0x0, > p_collecting= 0x0 > em1: lacp_sm_mux: state= 0x2, selected= 0x2, p_sync= 0x0, > p_collecting= 0x0 > [...] > > Not sure if the attachment will work to the list, but here is a pcap attached > em1 (sudo tcpdump -i em1 -s 0 -w lacp.pcap). Attaching to the lagg0 with > tcpdump, filters out the freebsd’s LACP packets, but still sees the TP-Link’s > packets. Did you remember to configure the switch to use LACP on those ports? It isn't automatic. And did you remember to manually up em1? Those are the two commonest LACP configuration mistakes. -Alan ___ 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: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working
On Dec 4, 2014, at 12:50 PM, Alan Somers wrote: >> Not sure if the attachment will work to the list, but here is a pcap >> attached em1 (sudo tcpdump -i em1 -s 0 -w lacp.pcap). Attaching to the lagg0 >> with tcpdump, filters out the freebsd’s LACP packets, but still sees the >> TP-Link’s packets. > > Did you remember to configure the switch to use LACP on those ports? > It isn't automatic. And did you remember to manually up em1? Those > are the two commonest LACP configuration mistakes. > > -Alan 99% sure the switch is configured correctly. I’ve actually tried all the different combination of the switch supports, and can’t seem to get them to sync up. From the pcaps, both the host and switch are sending the LACP packets … but it seems that the freebsd is just passing them through/up … almost like FreeBSD doesn’t recognized them as LACP packets. In looking a bit deeper on the pcaps in wireshark - the TP-Link’s packet correctly labels the “partner” systems to the super micro/freebsd box by port and mac address, however the FreeBSD response has all zeros for the partner systems mac and port. So without looking at the logs on the switch, my guess is the switch correctly sees the FreeBSD box, however the FreeBSD box is not correctly recognizing the packets from the switch as LACP. Feels like a single bit or flag in the switches packets that is not matching what FreeBSD is expecting. I was hoping someone would have some insight before I start looking at each bit of the packets what’s not aligned. - David P. Discher http://davidpdischer.com/ AIM: DavidDPD | Y!M: daviddpdz signature.asc Description: Message signed with OpenPGP using GPGMail
Re: problem with 9k jumbo clusters
I had wanted to remove the larger cluster sizes from the driver a while back, but for reasons I don't remember that code change didn't happen. The new 40G ixl driver does this, it only uses standard clusters for anything under 2K, and above that everything uses 4K. I would be curious to see if this change would resolve your problem, would you like a patch, or are you able to hack the code yourself to do this? Jack On Thu, Dec 4, 2014 at 11:00 AM, Alexander V. Chernikov < melif...@freebsd.org> wrote: > On 04.12.2014 13:50, Yuriy Tabolin wrote: > >> Hi All. >> I have a server with two Intel 10G NIC. OS FreeBSD 10.1-Release amd64. >> Server works like NFS, samba-server and iSCSI target. Both NICs aggregated >> into lagg device and set MTU 9014 to them. There are some tuning >> sysctl.conf: >> kern.maxfiles=6289601 >> kern.maxfilesperproc=5660640 >> kern.maxvnodes=3339565 >> kern.ipc.nmbclusters=12255588 >> kern.ipc.nmbjumbop=6127794 >> kern.ipc.nmbufs=78435780 >> kern.ipc.maxsockbuf=16777216 >> kern.ipc.maxsockets=6289600 >> net.inet.tcp.sendbuf_max=16777216 >> net.inet.tcp.sendspace=65536 >> net.inet.tcp.recvbuf_max=16777216 >> net.inet.tcp.recvspace=65536 >> >> After some days of working, the errors are appearing: >> ix1: Interface stopped DISTRIBUTING, possible flapping >> ix0: Interface stopped DISTRIBUTING, possible flapping >> ix0: Could not setup receive structures >> ix1: Could not setup receive structures >> > Hello. It looks like > https://lists.freebsd.org/pipermail/freebsd-net/2014-May/038630.html > is relevant here. > > >> After that errors the NICs stoped working. netstat -m shows: >> 32881/33854/66735 mbufs in use (current/cache/total) >> 16370/8198/24568/12255588 mbuf clusters in use (current/cache/total/max) >> 16370/4807 mbuf+clusters out of packet secondary zone in use >> (current/cache) >> 0/873/873/6127794 4k (page size) jumbo clusters in use >> (current/cache/total/max) >> 16383/21517/37900/1815641 9k jumbo clusters in use >> (current/cache/total/max) >> 0/0/0/1021298 16k jumbo clusters in use (current/cache/total/max) >> 188407K/222004K/410411K bytes allocated to network (current/cache/total) >> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >> 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) >> 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) >> 0/101414306/0 requests for jumbo clusters denied (4k/9k/16k) >> 0 requests for sfbufs denied >> 0 requests for sfbufs delayed >> 0 requests for I/O initiated by sendfile >> >> 9k jumbo clusters max is too big, but looks like system cannot allocate >> them. There are huge number of "9k requests for jumbo clusters denied". >> ifconfig ix down/up don't helped, reboot is needed. Thanks for any help! >> >> >> -- >> Best regards, >> Tabolin Yuriy >> System administrator >> Speech Technology Center >> ___ >> 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: NICs devices switches "pshycial" place on each boot
> ===
> I tried that as well, but $device-name is empty.
>
> If I do this:
>
> notify 1000 {
> match "system" "USB";
> match "subsystem" "INTERFACE";
> match "vendor" "0x0b95";
> match "product" "0x1790";
> match "sernum" "249B0DE00C";
> match "type" "ATTACH";
> action "logger DEVICE NAME IS: $device-name.";
> };
> ===
>
> Maybe devd does'nt parse quite the same as sh(1), in that your trailing
> '.' might be seen as part of the name to match? Tried leaving it off?
Yes, I have remove the trailing '.', but $device-name is empty.
> Notice the "Dec 4 05:44:14 gateway1 martin: DEVICE NAME IS: .!" part.
> ===
>
> See above maybe, but then, where did that trailing '!' come from?
That was me making a mistake in the email.
With the following I can get the device-name "axge0", but I don't know how to
create
a usable NIC interface name for that.
attach 1000 {
device-name "axge[0-9]+";
match "vendor" "0x0b95";
match "product" "0x1790";
match "sernum" "249B0DE00C";
action "logger DEVICE NAME IS: $device-name";
};
Dec 4 06:41:39 gateway1 devd: Executing 'logger DEVICE NAME IS: axge0'
Dec 4 06:41:39 gateway1 martin: DEVICE NAME IS: axge0
What action would I then take to create a usable device for ifconfig?
Doing this doesn't work:
# ifconfig axge0 name lan1 inet 192.168.1.1 netmask 255.255.255.0
ifconfig: interface axge0 does not exist
Kind regards.
___
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: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working
On 12/04/2014 16:10, David P. Discher wrote: > > On Dec 4, 2014, at 12:50 PM, Alan Somers wrote: > >>> Not sure if the attachment will work to the list, but here is a pcap >>> attached em1 (sudo tcpdump -i em1 -s 0 -w lacp.pcap). Attaching to the >>> lagg0 with tcpdump, filters out the freebsd’s LACP packets, but still sees >>> the TP-Link’s packets. >> >> Did you remember to configure the switch to use LACP on those ports? >> It isn't automatic. And did you remember to manually up em1? Those >> are the two commonest LACP configuration mistakes. >> >> -Alan > > > > 99% sure the switch is configured correctly. I’ve actually tried all the > different combination of the switch supports, and can’t seem to get them to > sync up. From the pcaps, both the host and switch are sending the LACP > packets … but it seems that the freebsd is just passing them through/up … > almost like FreeBSD doesn’t recognized them as LACP packets. > > In looking a bit deeper on the pcaps in wireshark - the TP-Link’s packet > correctly labels the “partner” systems to the super micro/freebsd box by port > and mac address, however the FreeBSD response has all zeros for the partner > systems mac and port. So without looking at the logs on the switch, my > guess is the switch correctly sees the FreeBSD box, however the FreeBSD box > is not correctly recognizing the packets from the switch as LACP. > > Feels like a single bit or flag in the switches packets that is not matching > what FreeBSD is expecting. > > I was hoping someone would have some insight before I start looking at each > bit of the packets what’s not aligned. > > > > - > David P. Discher > http://davidpdischer.com/ > AIM: DavidDPD | Y!M: daviddpdz > Is the switch side set to "active" for the lacp mode (instead of passive)? Also, try: sysctl net.link.lagg.0.lacp.lacp_strict_mode=0 If either of those work, I'll explain more, don't have time to dig for old email right this minute. ___ 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: NICs devices switches "pshycial" place on each boot (SOLVED)
On 4 December 2014 at 14:24, Martin Hanson wrote: > It is worth mentioning that the ONLY reason why this worked is because > the vendor has provided a serial number. Most vendors don't and it > would not have worked then. > > devd NEEDS to be able to see device MAC addresses! I'm surprised it doesn't! Would you mind filing a PR so we do expose that particular bit of data? -a ___ 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: NICs devices switches "pshycial" place on each boot (SOLVED)
I managed to get this working.
It is a dirty hack and I REALLY wish FreeBSD would make documentation
as high a priority as the guys at OpenBSD.
It is difficult to locate correct and updated documentation, especially
about devd. Yes, the man page has information about devd, and devd.conf
even come with examples, but those examples are too sparsome to be of
any real use when things get just a little bit complicated.
It is extremely frustration to spend hour of hours of wasted time
getting something to work, not because it doesn't work, but simply
because you're "throwing stones in the dark" in the hopes of hitting
the right target - because the correct and comprehensive documentation
is lacking.
A quality product HAS to have correct, updated and comprehensive
documentation. This is one point that really makes the OpenBSD guys
stand out deserving laud applause.
Now, the driver on OpenBSD didn't work, so I had to use FreeBSD because
that driver works, otherwise I would never had ventured into this
incredible time consuming task.
Warren Block, thank you a billion times for helping me with correct and
relevant information!
This is what I did to make it work. Like I said, it is a hack, but hey
it works.
attach 100 {
device-name "axge[0-9]+";
match "vendor" "0x0b95";
match "product" "0x1790";
match "sernum" "249B0DE00C";
# We need to wait a little for the interface to get up.
action "sleep 3";
# We don't know what number the interface has been assigned, but we know it
is from axgeX,
# so we get the X, use it in "ueX" and then rename the interface which is
then bound to the
# serialnumber, so the correct card will always get the right interface,
ie. our own, not ueX.
action "ifconfig ue`echo $device-name | tr -dc '[0-9]'` name olan";
action "ifconfig olan inet 192.168.1.1 netmask 255.255.255.0";
};
I hope someone else might find this useful or perhaps even provide a cleaner
approach.
Kind regards.
___
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: NICs devices switches "pshycial" place on each boot (SOLVED)
It is worth mentioning that the ONLY reason why this worked is because the vendor has provided a serial number. Most vendors don't and it would not have worked then. devd NEEDS to be able to see device MAC addresses! ___ 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: NICs devices switches "pshycial" place on each boot (SOLVED)
On Thu, 4 Dec 2014, Martin Hanson wrote:
I managed to get this working.
It is a dirty hack and I REALLY wish FreeBSD would make documentation
as high a priority as the guys at OpenBSD.
It is difficult to locate correct and updated documentation, especially
about devd. Yes, the man page has information about devd, and devd.conf
even come with examples, but those examples are too sparsome to be of
any real use when things get just a little bit complicated.
It is extremely frustration to spend hour of hours of wasted time
getting something to work, not because it doesn't work, but simply
because you're "throwing stones in the dark" in the hopes of hitting
the right target - because the correct and comprehensive documentation
is lacking.
A quality product HAS to have correct, updated and comprehensive
documentation. This is one point that really makes the OpenBSD guys
stand out deserving laud applause.
We work at it, but it is difficult to cover everything. It would be
nice to have a section in the Handbook on devd. If you would like to
submit or work on something like that, I can help (I'm a doc committer).
attach 100 {
device-name "axge[0-9]+";
match "vendor" "0x0b95";
match "product" "0x1790";
match "sernum" "249B0DE00C";
# We need to wait a little for the interface to get up.
action "sleep 3";
# We don't know what number the interface has been assigned, but we know it
is from axgeX,
# so we get the X, use it in "ueX" and then rename the interface which is
then bound to the
# serialnumber, so the correct card will always get the right interface, ie.
our own, not ueX.
action "ifconfig ue`echo $device-name | tr -dc '[0-9]'` name olan";
action "ifconfig olan inet 192.168.1.1 netmask 255.255.255.0";
};
I hope someone else might find this useful or perhaps even provide a cleaner
approach.
There are several similar ways to deal with the device name. For
example:
action "ifconfig `echo $device-name | sed -e 's/axge/ue/'` name olan inet
192.168.1.1/24";
action "ifconfig ue${device-name##axge} name olan inet 192.168.1.1/24";
(Untested, and sorry about wrapping.) Both examples use the shorter
CIDR notation for the netmask, and set the name and IP address at the
same time... which ought to work, but I did not test.
___
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"
Panic after iwn0 controller panic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
I have seen this in the morning when I had an overnight replication
from my laptop to my storage system which transfers a lot of data.
Before the panic there was some message like:
iwn0: iwn_panicked: controller panicked, iv_state = 5; resetting...
iwn0: iwn_read_firmware: ucode rev=0x12a80601
iwn0: iwn_tx_data: m=0xf8001d780300: seqno (61735) (39) != ring
index (0) !
Then the panic with fault virtual address (0x1f, which seems to be
mbuf->mflags).
Call trace was:
ithread_loop -> intr_event_execute_handlers -> iwn_intr ->
iwn_notif_intr -> iwn_ampdu_tx_done@3717 -> ieee80211_tx_complete@3417
So looks like 'm' was NULL in ieee80211_tx_complete. I don't have
INVARIANTS enabled or the panic should be earlier as there is an
assertion in iwn(4) right before calling ieee80211_tx_complete:
KASSERT(m != NULL, ("no mbuf"));
I haven't looked at the issue further yet as I haven't idea how to
provoke the issue again.
Cheers,
- --
Xin LI https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.0 (FreeBSD)
iQIcBAEBCgAGBQJUgPauAAoJEJW2GBstM+nsYHcP/187em+bzP6QW7jw6H+cGwI/
NMi2862SL2NfV+0eQt2zPtUd2MmQZzraT13KumAW5uZ3jOBvRxzjnxJq5Ljv6xP/
T+IwLJ/Tu1Yc+oEcWB0CucDU3Xmsbln1iOo5Wwez/Hs0nllvg+jiwMlUgd6zanxN
rxldI9xRgEKKLplCWhhIRODC7JFD4kyftPPMafxEVPXVBtgTtr5Yt0uk/1Nr5aii
Quct6QbdpT2epa9wpb2Z5VUgLfafOJ43XWpTdI0xXPxkjqQcBf6E4SoVsxoNQ6IM
33BRye/G0RBkSvWSGaSw6DlqYtSU/NG8Wx4JeEjH71Bm6wE2kk9AU3mvcE/cYGdh
INKNw4gpP4EDM1v8mhJjRQIOHON2WEaRH535+zJ16v+KERRKmA9BjDPZh/TSC8CF
zBRsHrO1SiS0A1tjccOBBOhSKBBvWwH+fVGtsYLRlmkVF/qzGZqYDnvdDskMKPF9
hAJr3ZU8lC6aja44+qKR3z6m5XxnTGqO1kgIrisQHNBydH3HW5MZLbv9Muf/PWqo
caJ04rtC1AQfE9N50l3fYsqvAyAncraCaEiaeQQ2oSNO5ruAm0OjjUQBcAq9xGw8
qEjkFHAbxrOV15y5qXSKkSV80rE5/ve1JEbQqGxhhplMc8DPrc4ZS5AIuujOeJvd
oaIMRMYo83HUraRy54SN
=0TDK
-END PGP SIGNATURE-
___
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: NICs devices switches "pshycial" place on each boot (SOLVED)
On Thu, 4 Dec 2014 14:41:11 -0800 Adrian Chadd wrote > On 4 December 2014 at 14:24, Martin Hanson > wrote: > It is worth mentioning that the ONLY reason why this worked is > because > the vendor has provided a serial number. Most vendors don't and it > > would not have worked then. > > > > devd NEEDS to be able to see device MAC addresses! > > I'm surprised it doesn't! Really? I ran into a situation ~2yrs ago trying to manage a dongle based IF, in an effort get it to work with the upstream, that required MAC based authentication. It's in the list archives, somewhere. :) > Would you mind filing a PR so we do expose > that particular bit of data? I'll be happy to do it, myself, now. I'm going to building a wireless switch, and will be doing *quite* a bit of work in this area. So will likely be making contributions, and would like to be kept in the loop. :) @Martin, Thank you very much for your diligence, and for sharing your experience, and *especially* your solution. @Warren; Thanks for your continued dedication! --Chris > > > > -a > ___ > 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: NICs devices switches "pshycial" place on each boot (SOLVED)
On Thu, 04 Dec 2014 16:32:04 -0800 "Chris H" wrote > On Thu, 4 Dec 2014 14:41:11 -0800 Adrian Chadd wrote > > > On 4 December 2014 at 14:24, Martin Hanson > > wrote: > It is worth mentioning that the ONLY reason why this worked is > > because > the vendor has provided a serial number. Most vendors don't and > > it > would not have worked then. > > > > > > devd NEEDS to be able to see device MAC addresses! > > > > I'm surprised it doesn't! > Really? I ran into a situation ~2yrs ago trying to manage > a dongle based IF, in an effort get it to work with the > upstream, that required MAC based authentication. It's > in the list archives, somewhere. :) > > > Would you mind filing a PR so we do expose > > that particular bit of data? > I'll be happy to do it, myself, now. Ahh looks like Martin got the jump on me: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195692 > I'm going to building > a wireless switch, and will be doing *quite* a bit of work in > this area. So will likely be making contributions, and would > like to be kept in the loop. :) > > @Martin, Thank you very much for your diligence, and for > sharing your experience, and *especially* your solution. > > @Warren; Thanks for your continued dedication! > > --Chris > --Chris > > > > > > > > -a > > ___ > > 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: FreeBSD 10-stable (r274577) LACP / IEEE 802.3ad with TP-Link TL-SG2008 - not working
Thanks Adam - On Dec 4, 2014, at 1:58 PM, Adam McDougall wrote: > > Is the switch side set to "active" for the lacp mode (instead of > passive)? Also, try: > sysctl net.link.lagg.0.lacp.lacp_strict_mode=0 > > If either of those work, I'll explain more, don't have time to dig for > old email right this minute. Yes, the switch was in active mode. Turn strict mode off (which I thought I did before, but of course this sysctl clears when destroying the interface). So, the LACP did finally negotiated, at least in ifconfig : lagg0: flags=8843 metric 0 mtu 1500 options=4219b ether 00:30:48:35:cc:25 inet 192.168.0.50 netmask 0xff00 broadcast 192.168.0.255 inet6 fe80::230:48ff:fe35:cc25%lagg0 prefixlen 64 scopeid 0x4 nd6 options=21 media: Ethernet autoselect status: active laggproto lacp lagghash l2,l3,l4 laggport: em1 flags=1c lacp debug shows good info - though the partner info from the freebsd host is still zeros. em1: lacpdu transmit actor=(8000,00-30-48-35-CC-25,008B,8000,0002) actor.state=7d partner=(,00-00-00-00-00-00,,,) partner.state=3c maxdelay=0 But it’s not passing any traffic. The switch however does not see the mac address via lagg0. Turning lagg0 off, and just running em1, with the same ip, it works. Got ssh going on the switch: TL-SG2008#show mac address-table interface gigabitEthernet 1/0/5 MACvlan-id port typeaging ------ - TL-SG2008# TL-SG2008#show lacp internal Flags: S - Device is requesting Slow LACPDUs F - Device is requesting Fast LACPDUs A - Device is in active mode P - Device is in passive mode Channel group 4 LACP port Admin OperPortPort Port Flags State Priority Key Key Number State Gi1/0/5 SA Up32768 0x4 0x270 0x5 0x5 Channel group 5 LACP port Admin OperPortPort Port Flags State Priority Key Key Number State Gi1/0/8 SA Up32768 0x5 0x35f 0x8 0x7d Doing another pcap on the lagg0 and em1 … the arp is being sent on the lagg … however it is not being past down to em1. What even makes less sense, as typing this email … the ping to my MacBook (with has staticly assigned 192.168.0.2) wakes up, but the ping from my macbook to the NAS-lagg (192.168.0.50) doesn’t do anything. PCAP of em1 while this is was happening, shows nothing. [ pts/0 nas.dpdtech.com:~ ] [ dpd ]> ping 192.168.0.2 PING 192.168.0.2 (192.168.0.2): 56 data bytes 64 bytes from 192.168.0.2: icmp_seq=13 ttl=64 time=1.127 ms 64 bytes from 192.168.0.2: icmp_seq=14 ttl=64 time=0.987 ms 64 bytes from 192.168.0.2: icmp_seq=15 ttl=64 time=95.997 ms 64 bytes from 192.168.0.2: icmp_seq=16 ttl=64 time=108.118 ms 64 bytes from 192.168.0.2: icmp_seq=17 ttl=64 time=1.033 ms 64 bytes from 192.168.0.2: icmp_seq=62 ttl=64 time=0.975 ms 64 bytes from 192.168.0.2: icmp_seq=63 ttl=64 time=1.050 ms 64 bytes from 192.168.0.2: icmp_seq=64 ttl=64 time=1.002 ms 64 bytes from 192.168.0.2: icmp_seq=65 ttl=64 time=1.029 ms 64 bytes from 192.168.0.2: icmp_seq=66 ttl=64 time=1.079 ms 64 bytes from 192.168.0.2: icmp_seq=70 ttl=64 time=0.957 ms 64 bytes from 192.168.0.2: icmp_seq=90 ttl=64 time=0.987 ms 64 bytes from 192.168.0.2: icmp_seq=92 ttl=64 time=0.988 ms 64 bytes from 192.168.0.2: icmp_seq=93 ttl=64 time=1.050 ms 64 bytes from 192.168.0.2: icmp_seq=94 ttl=64 time=88.678 ms 64 bytes from 192.168.0.2: icmp_seq=95 ttl=64 time=1.059 ms 64 bytes from 192.168.0.2: icmp_seq=120 ttl=64 time=1.118 ms 64 bytes from 192.168.0.2: icmp_seq=121 ttl=64 time=1.276 ms 64 bytes from 192.168.0.2: icmp_seq=144 ttl=64 time=53.300 ms 64 bytes from 192.168.0.2: icmp_seq=191 ttl=64 time=93.479 ms 64 bytes from 192.168.0.2: icmp_seq=192 ttl=64 time=68.839 ms 64 bytes from 192.168.0.2: icmp_seq=193 ttl=64 time=1.019 ms 64 bytes from 192.168.0.2: icmp_seq=194 ttl=64 time=1.096 ms 64 bytes from 192.168.0.2: icmp_seq=195 ttl=64 time=1.031 ms 64 bytes from 192.168.0.2: icmp_seq=241 ttl=64 time=0.993 ms 64 bytes from 192.168.0.2: icmp_seq=242 ttl=64 time=1.095 ms 64 bytes from 192.168.0.2: icmp_seq=243 ttl=64 t
