[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Intel X540-AT2 and Debian: intermittent connection



On 11/19/22 15:51, hw wrote:
On Sat, 2022-11-19 at 13:35 -0800, David Christensen wrote:
On 11/19/22 06:50, hw wrote:
On Fri, 2022-11-18 at 17:02 -0800, David Christensen wrote:

... I suggest trying a Category 6A factory patch cable at least 2 meters
long.

I tried it with a 10m cat6 cable and the connection was intermittent.  It's
the
same (as in "identical to") cable that works between the other server and a
client.


Okay.  I suggest putting a unique mark/ serial number on each cable for
tracking purposes until you resolve the intermittent connection issue.

What for?  All the cables I used except for the new ones are known good.


Sanity check/ OCD. I went through a period with SATA III drive problems and marked all of my SATA cables to help with troubleshooting.


What OS's for the various machines?

Fedora on the server and Debian on the backup server, Fedora on the client.


Okay.  If the NIC works correctly in the backup server with Fedora,
maybe you should just use Fedora.

Unfortunately it doesn't work anymore with Fedora either ...  I tried it with a
live system if it would work and it didn't.


Okay.


Perhaps that is a good reason to do some devops development -- e.g.
write a data-driven script that reads a configuration file to
interconnect the VM virtual network interfaces and host physical network
interfaces.

Why would I do that?  How would a script figure out which interface is which and
how would it guarantee that they will be exactly the same as seen by OPNsense
running in that VM when I switch them around?  I'm not saying it's impossible,
but I'd rather resolve this problem in a timely manner and not in a couple years
when I might have finished the script and tested it in a bunch of servers which
aren't even relevant.


I agree that creating software for devops can be difficult and time consuming, but it is nice to have when done. I have built up a collection of shell and Perl scripts over the years that are very useful.


I suspect it's a mainboard issue.


The clues support that hypothesis.


  I pulled the Intel card and then the on-
board
network card quit working.


With the current Debian installation?

yes

Did you try the d-i rescue shell

You mean the rescue system that comes with the Debian installer?  No, I haven't.
How would that make a difference?


It would provide data point for troubleshooting.


or any live sticks?

only the Fedora one


That indicates a bad NIC and/or a bad PCIe slot.


I plugged the Intel card back in and the on-card
worked again.  I'd try disabling the on-board card but there is no option to
do
that in the BIOS.

Okay.  That indicates the issue is software.

How would it be a software issue affecting a network card from a totally
different manufacturer in a PCI slot that the BIOS doesn't have an option to
disable the on-board network card?


Without extensive engineering information and the right test equipment, who knows?


At this point, all I can suggest is a program of A/B testing to isolate
the faulty hardware and/or software component(s).  Beware that you may
have multiple faults, so be meticulous.

The only thing I can do is try the network card that's in the client now.  It'll
be about a week before I can get to that.

I prefer FreeBSD for my servers.  The "Intel ® Ethernet Controller
Products 27.7 Release Notes" indicate the "ix" driver is supported and
tested on FreeBSD 13 and FreeBSD 12.3 ("Fedora" and "Debian" appear
nowhere in that document):

Good idea, I can try this maybe: https://www.nomadbsd.org/

I'd be surprised if it worked, but maybe it does and if it does, I could just as
well use FreeBSD for the backup server.


It sounds like you could use more spare parts and/or computers.


Let us know what happens with the Broadcom card and with whatever BSD you pick (the FreeBSD installer includes a rescue shell and a live system).


David


Reply to: