Date: Sun, 20 Aug 2023 11:38:12 -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

     I haven't seen any response to this.  Note I can pretty much 
guarantee this is not an issue with any distribution of kernel version 
at this point.  This is almost certainly an issue of my own making, but 
that does not mean I need to get it resolved any less.  I strongly 
suspect the problem is something I did in the udev rules that is now 
preventing the network system from recognizing the presence of the  
network card.  Assuming for the time being this is the case, how do I 
get the system to recognize the presence of the card in order to get it 
to assign a network interface to it?

On 8/14/2023 8:50 PM, Leslie Rhorer wrote:
>
>
> 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