lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <edfeb028-02cb-35b1-e828-9b5931c8d65a@att.net>
Date: Mon, 14 Aug 2023 20:50:36 -0500
From: Leslie Rhorer <lesrhorer@....net>
To: Bagas Sanjaya <bagasdotme@...il.com>,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 Linux Networking <netdev@...r.kernel.org>, Ariel Elior <aelior@...vell.com>
Subject: Re: Failing network hardware



On 8/14/2023 8:20 PM, Bagas Sanjaya wrote:
> (fixing up netdev address)
> 
> On Sun, Aug 13, 2023 at 01:53:58PM -0500, Leslie Rhorer wrote:
>> Hello all,
>>
>> 	About a year or so ago, I upgraded one of my Debian servers to Bullseye,
>> and it killed the 10G NIC on the server due to issues with the device driver
>> in the Debian repository (it was missing).  I jumped through all sorts of
>> loops and hoops to try to get it working, but I finally had to give up and
>> resort to using the 1G interface.  Recently, I tried a new install on a
>> different server to the new Debian Bookworm, and it worked for that server,
>> so apparently the issue has been fixed in Bookworm.  I reported a bug
>> against the Buster distribution, but it was never fixed.
>>
>> 	With that in mind, I went ahead and upgraded the original server to
>> Bookworm, but the NIC remains dead.  Unfortunately, I cannot find my notes
>> on what I did originally to try to get the 10G interface working and to shut
>> it down in favor of a built-in port.  I do recall I tried compiling what was
>> supposed to be the correct firmware driver and also changing the udev rules,
>> but I do not recall the exact details.  I have tried several things,
>> including re-installing the firmware, but nothing seems to work.  The
>> Ethernet interface does not appear on the system in order to be able to
>> specify it in /etc/network/interfaces.  What can I do in order to try to get
>> the 10G card working?
>>
>> 	The card is an Asus MCB-10G_PEB-10G NIC and uses the bnx2x.ko driver. The
>> system uses an Asus AMD-64 motherboard.  The bnx2x.ko driver is installed,
>> and lspci shows the card in the system, but ifconfig does not see the
>> interface.
>>
> 
> Too many moving parts here, hence allow me to rule things out:
> 
> If there is any of your system haven't been dist-upgraded to bookworm, can you
> confirm this issue on vanilla v6.1 kernel? 

	One, named Backup, is a fresh install of Debian Bookworm.  The NIC on 
Backup works just fine.  The other, named RAID-Server, was upgraded via 
dist-upgrade from Buster to Bullseye, at which point the NIC quit 
working, and then from Bullseye to Bookworm.

	I identified the problem on Bullseye and submitted a bug report, but no 
one ever bothered to fix the bug, which was simply the fact the driver 
was missing from the Bullseye distro.

	Both systems are now running kernel 6.1.0-10-AMD64.

> And also, can you check latest mainline?

	I don't know what you mean by that.

> If all have been upgraded, though, you need to reinstall bullseye
> first.

	I take it by that, you are making the distinction between an upgrade 
from an older distro and kernel to a new one and a fresh install of a 
distro running a 6.1 kernel?

	I definitely do not want to re-install Bullseye on either system.  It 
would break Backup's NIC to do so, and it would be an incredible mess 
with a potentially unacceptably long down time to try to back out of 
Bookworm on RAID-Server.  If I follow your intent, however, this should 
be unnecessary.  I have one working fresh install and one broken 
dist-upgrade from a known broken distribution.

> As a side note, when you reply to mailing lists, please don't top-post;
> reply inline with appropriate context instead.

	That is my usual practice.  It has been for many decades.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ