[Bug 211219] NIC status does not pass into a state of "no carrier" after disconnecting the cable.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211219
--- Comment #18 from Franco Fichtner ---
The second line in the if statement still differs in the way introduced by the
original commit causing the regression:
Original Intel driver and requested in this this PR/attached commit:
ims_mask |= EM_MSIX_MASK;
Current state on all branches:
ims_mask |= adapter->ims;
In our conversations you asked me which of the two lines were needed, because
the chip documentation wasn't clear.
The testing result for a good result (for two distinct devices I have) was:
if (hw->mac.type == e1000_82574) {
E1000_WRITE_REG(hw, EM_EIAC, adapter->ims);
}
The current FreeBSD state was changed to read this:
if (hw->mac.type == e1000_82574) {
E1000_WRITE_REG(hw, EM_EIAC, adapter->ims);
ims_mask |= adapter->ims;
}
Which still differs from the good tested result or the original Intel state.
Either the second line should be dropped or changed to how it reads in the
Intel driver.
Cheers,
Franco
--
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 211219] NIC status does not pass into a state of "no carrier" after disconnecting the cable.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211219
--- Comment #19 from Sean Bruno ---
(In reply to Franco Fichtner from comment #18)
Is it possible that you are looking at a different source tree than I?
stable/11 currently has the following:
static void
em_enable_intr(struct adapter *adapter)
{
struct e1000_hw *hw = &adapter->hw;
u32 ims_mask = IMS_ENABLE_MASK;
if (hw->mac.type == e1000_82574) {
E1000_WRITE_REG(hw, EM_EIAC, EM_MSIX_MASK);
ims_mask |= adapter->ims;
}
E1000_WRITE_REG(hw, E1000_IMS, ims_mask);
}
--
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"
Problem reports for freebsd-net@FreeBSD.org that need special attention
To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status |Bug Id | Description +---+--- In Progress |165622 | [ndis][panic][patch] Unregistered use of FPU in k In Progress |203422 | mpd/ppoe not working with re(4) with revision 285 In Progress |206581 | bxe_ioctl_nvram handler is faulty New |204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New |205592 | TCP processing in IPSec causes kernel panic New |206053 | kqueue support code of netmap causes panic New |213410 | [carp] service netif restart causes hang only whe New |215874 | [patch] [icmp] [mbuf_tags] teach icmp_error() opt New |217748 | sys/dev/ixgbe/if_ix.c: PVS-Studio: Assignment to Open|173444 | socket: IPV6_USE_MIN_MTU and TCP is broken Open|193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open|194485 | Userland cannot add IPv6 prefix routes Open|194515 | Fatal Trap 12 Kernel with vimage Open|199136 | [if_tap] Added down_on_close sysctl variable to t Open|202510 | [CARP] advertisements sourced from CARP IP cause Open|206544 | sendmsg(2) (sendto(2) too?) can fail with EINVAL; Open|211031 | [panic] in ng_uncallout when argument is NULL Open|211962 | bxe driver queue soft hangs and flooding tx_soft_ 18 problems total for which you should take action. ___ 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 218653] Intel e1000 network link drops under high network load
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218653 Kaho Toshikazu changed: What|Removed |Added CC||k...@elam.kais.kyoto-u.ac.j ||p --- Comment #3 from Kaho Toshikazu --- (In reply to nn from comment #1) I think the link drop itself is caused by a Tx error, but you have many Rx errors shown by the Ierrs of the netstat output and you should investigate what errors occur at first. Can you see a `sysctl dev.em.0` result? Can you get which knobs related errors are increasing their counters? For example, does rx_overrun or crc_errs has a non-zero value? -- 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"
Small socket programming question
Sorry, I -think- I know that answer to this question, but I'd prefer to ask and make sure, in case I have misunderstood things. I am aware that for any open socket, the kernel sets aside some amount of buffer space for that socket. (And yes, I *do* also know that the specific amount set aside may be programatically controlled.) So anyway, let's say that I have either a RAW or UDP (datagram) socket open and my program is running on a nice fast machine, but it's outbound connection is via a rather slow link. So if my program writes and writes and writes to this socket, eventually, I'll have used up all of the buffer space that the kernel has associated with the socket. My question is just this: What happens then? Will further writes to the socket block until some more packets get sent out, you know, so that there is once again room in the outbound buffer that's associated with this socket? Or will I instead get some error back from the call to write(), like for instance EAGAIN or ENOSPC or maybe ENOBUFS? Or does the kernel in such cases just silently discard one or more of my precious outbound packets without even telling me? (I guess this is my way of asking whether or not the FreeBSD kernel may, in some cases, itself be a source of "packet loss".) Thanks in advance for any & all enlightening replies. ___ 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 218687] [patch] use uninitialized fields of struct inpcb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218687 Mark Linimon changed: What|Removed |Added 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"
