Dear Leslie, I'm sorry no one noticed your bug. Reply follows inline: Jeremy, thank you for following up on this bug! This brought the bug to my attention :) Leslie Rhorer <lesrhorer@siliconventures.net> writes: > On 7/13/2023 5:18 PM, Jeremy Davis wrote: >> [Just a random passer-by that might have an idea?] >> >> It looks to me like you are missing the firmware-realtek[1][2] >> (non-free) package?! > > No, I am not missing it. The package is broken in Bullseye. The > firmware is there, but does not work. It worked just fine in Buster, > but when I upgraded to Bullseye, the 10G NIC completely quit working. > It's been over a year, so I don't recall everything I did, but I spent > many, many hours trying to get the new firmware working, and many more > hours trying to extract the firmware from the oldstable package, and > then quite a few more hours trying to compile from source, but nothing > worked. I could not even get the source code to compile. Given your intention to upgrade from buster to bullseye, here is what you can try (please read to the end of this email first, because an alternative method is a better use of your time): 1a. Enable bullseye-backports (non-free), and 'apt install -t bullseye-backports firmware-linux firmware-misc-nonfree' which is currently 20230210-4~bpo11+1 2a. Reboot 3a. If both your NICs work, then it's a firmware bug. If this is the case, please report a bug against firmware-linux-nonfree 20210315-3. -- 1b. If the steps above are insufficient, 'apt install -t bullseye-backports linux-image-amd64' which is currently 6.1.20-2~bpo11+1 2b. Reboot. GRUB should automatically choose the backports kernel. 3b. Your NICs should work at this point. If they do, and you'd like to report a bug against the linux-image-amd64 version in bullseye, then please go ahead and do so, but please make sure that you've tested 5.10.178-3 before doing so:) > The bottom line is the firmware from the Buster non-free distro > works perfectly well, but noone has come forth with a fix for Bullseye, > and I have no reason to believe the firmware from Bookworm will work. > The NIC is an Asus PEB-10G/57811-1S 10GbE SFP+ Network Adapter which > employs a BCM 57811S controller. Maybe nobody knows that this specific hardware is broken? It may be that the Asus PEB-10G/57811-1S has some hardware quirks that Broadcom doesn't know about. In your original bug log you'll notice this snippet >>>> RTL8211E Gigabit Ethernet which is the Realtek one, Gibabit, RJ45 copper. I wonder if this one is a completely different NIC built into your motherboard. ie: the historically very buggy Realtek 8111E? Alternatively, if the 10GbE SFP+ PCIe adapter NIC uses a Realtek for gigabit PHY, then the nature of the bug could be that both both Realtek and Broadcom broke your NIC (either in the firmware on in the driver, or both). >> If you haven't already tried, I'd suggest that you try a clean >> bookworm install from ISO. FWIW bookworm now includes a separate >> "non-free-firmware" repo that is enabled by default. So the official >> installer should "just work". > I can try, but I really would not be well advised to do so until I > can get the dead system working again. Jeremy is right about how bookworm includes non-free-firmware by default, and also that the state of your hardware with bookworm should be tested first. The best use of your time will be to test with live media (USB or DVD). If you'd like to have a GUI for your test, please choose a variant you recognise and are comfortable with. The "standard" flavour is CLI only, which--alternatively--might be what you want (it's a smaller download ). https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/ If the problem still exists in bookworm, then it needs to be fixed in bookworm before the fix can be backported to buster, and the live media is the fastest way to test this. Regards, Nicholas
Attachment:
signature.asc
Description: PGP signature