Bug 230807 - if_alc(4): Driver not working for Killer Networking E2200
Summary: if_alc(4): Driver not working for Killer Networking E2200
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Many People
Assignee: freebsd-net (Nobody)
URL: https://forums.freebsd.org/threads/se...
Keywords: needs-qa, patch
Depends on:
Reported: 2018-08-21 18:42 UTC by Daniel McKee
Modified: 2020-01-25 08:36 UTC (History)
7 users (show)

See Also:
koobs: mfc-stable12?
koobs: mfc-stable11?


Note You need to log in before you can comment on or make changes to this bug.
Description Daniel McKee 2018-08-21 18:42:22 UTC
Driver loads, but will not pick up DHCP nor will a static IP address yield any IP traffic -- Cannot even ping the gateway or any other device on the local network.

This driver worked previously.
Comment 1 Eugene Grosbein freebsd_committer 2018-08-22 15:32:40 UTC
(In reply to Daniel McKee from comment #0)

The driver worked previously - with same hardware? In what OS version/revision did it work? Please show lines concerning alc hardware from dmesg output and pciconf -lvv

Do you have any errors in dmesg output? Does "tcpdump -npi alc0" shows any incoming packets when you do your tests?
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2018-08-29 19:19:45 UTC
Please show us the exact revision you are running.  Thanks.
Comment 3 Daniel McKee 2018-09-14 19:26:53 UTC
I am mistaken.  It was not working previously.  However I did find this post as to a possible (?) fix;



        * Force maximum payload size to 128 bytes for
        * E2200/E2400/E2500.
        * Otherwise it triggers DMA write error.
       if ((sc->alc_flags & ALC_FLAG_E2X00) != 0)
           sc->alc_dma_wr_burst = 0;
Comment 4 Daniel McKee 2018-09-14 19:28:01 UTC

By adding the same last two lines (with modified if condition) and rebuilding the whole system, it works, but I don't know if it exactly works fine or not.
Comment 5 Mark Millard 2019-11-25 02:26:04 UTC
A ThreadRipper 1950X X399 AORUS gaming 7 I use has an E2500:

alc0: <Killer E2500 Gigabit Ethernet> port 0x1000-0x107f mem 0xba000000-0xba03ffff irq 27 at device 0.0 numa-domain 0 on pci5
alc0: 11776 Tx FIFO, 12032 Rx FIFO
alc0: Using 1 MSIX message(s).
alc0: 4GB boundary crossed, switching to 32bit DMA addressing mode.
miibus0: <MII bus> numa-domain 0 on alc0
atphy0: <Atheros F1 10/100/1000 PHY> PHY 0 on miibus0
atphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
alc0: Using defaults for TSO: 65518/35/2048
alc0: Ethernet address: . . .

(Note the numa domain use, in case numa matters for some reason.)

While Fedora (such as 31 now but for a long time) and Windows 10 Pro x64
(1903 now but for a long time) have had no problems using this EtherNet
interface when native-booted from their drives, I've historically either
booted the FreeBSD drive under HyperV so Windows would deal with the
EtherNet or used the poorly working WiFi for native FreeBSD.

This was not limited to any specific versions of FreeBSD but has been
true over some time. I recently jumped from head -r352341 to -r355027 and
the behavior did not change.

My experiments with things like "tcpdump -npi alc0" did not show packets
coming in.

I have not tried making any code changes.
Comment 6 Mark Millard 2020-01-08 03:56:13 UTC
(In reply to Mark Millard from comment #5)

While I was not looking for such at the time,
I noticed somewhat after switching to non-NUMA
on the ThreadRipper that the E2500 had started

I'm not aware of any other configuration change
that would be likely to have contributed.

It has been working ever since I switched to
non-NUMA. I waited to see if it would stay
operational for a time (weeks) before making
this comment.
Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2020-01-25 03:27:30 UTC
(In reply to Mark Millard from comment #6)

Can you try the patch mentioned in comment 3?

^Triage: Not a regression (comment 3)
Comment 8 Mark Millard 2020-01-25 08:36:11 UTC
(In reply to Kubilay Kocak from comment #7)

It is working without the patch when the threadripper 1950X ACPI is
configured as non-NUMA (via what the old Ryzen Master version calls
"distributed" mode).

I am no longer actively experimenting with NUMA mode for other
purposes, at least for now. So if I just applied the patch and
rebuilt and reinstalled, I'd just be testing if it stopped the
working context from working. That presumes that I understood
what the patch is to be, but I do not.

The way I read the forum message, the shown lines of code were
already in /usr/src/sys/dev/alc/if_alc.c and a somewhat different
pair of lines was to be put somewhere ("with modified if condition").
I've no clue what the modification was nor where the two new lines
were to be put. (Knowing the later might help identify the former
by giving a context to examine.)

Is the patch expected to be NUMA-specific as far as fixing things?
Are you asking that I try the patch when the ACPI information is
configured for NUMA (called "local" mode in that Ryzen Master)?

If yes-and-yes, then I'd first need to somehow identify the
specific patch to be made, unless someone that knows reports
the specifics that I should use. I have yet to figure this
out on my own.