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

Re: Intel X540-AT2 and Debian: intermittent connection



On Sun, 2022-11-20 at 10:46 +0100, hede wrote:
> On Sun, 20 Nov 2022 00:51:20 +0100 hw <hw@adminart.net> wrote:
> 
> > Unfortunately it doesn't work anymore with Fedora either ...  I tried it
> > with a
> > live system if it would work and it didn't.
> 
> The source of connection resets can be diverse.

Is it a connection reset?  I can ping for a short time, then the address is
unreachable, then the pings get through again.

> Sometimes dmesg will show useful info, sometimes not. It can be anything, from
> the link layer (ethernet re-negitiation) to some upper layers (arp, ip, etc.).
> What kind of logs and status apps did you examined already? (dmesg,
> ethtool/mii-tool, syslog, systemd journal, journal for which kind of services,
> etc.)

I checked dmesg and messages and that only shows when the link is up when I
unplug/plug the cable.  Ethtool doesn't show anything special, either.  There
are no services running using the card; it's sole purpose is to make backups
faster via rsync (I don't have a 10GB switch).

> Does the live system use the same kernel as the installed one? That's
> typically not the case as those get updated very frequently. As such the
> driver can still be different. (can, maybe, not a must)

I don't know, I'll try the Debian rescue and FreeBSD when the currently running
backups are finished.

> Does the X540-AT2 uses external or builtin firmware? With external firmware
> even that can differ between systems and firmware is also a potential source
> of connection problems. 

I don't know.  While I was trying to fix the problem, I installed the Linux
firmware package, and there doesn't seem to be a particular card for the card. 
I haven't seen any notices about firmware being loaded and having the firmware
package installed didn't make a difference.


dmesg | grep -i firm
[    0.156099] Spectre V2 : Enabling Restricted Speculation for firmware calls
[    0.895840] GHES: APEI firmware first mode is enabled by WHEA _OSC.
[    3.489013] 3w-sas: scsi0: Firmware FH9X 5.12.00.007, BIOS BE9X 5.11.00.006,
Phys: 8.
[    4.689010] 3w-sas: scsi7: Firmware FH9X 5.12.00.007, BIOS BE9X 5.11.00.006,
Phys: 8.


Hm, is it normal for both controllers to say 'Phys: 8'?  They are working fine,
but perhaps they're conflicting with the network card.

> For the cable: my own experience is that with shorter connections the cable is
> more irrelevant. On shorter connections even cat 5 works on 10 GBit. I had to
> use those for some room-to-room connection (wall-moulded cables for fire
> protection between two adjacent rooms, not simply exchangeable). They are
> perfectly working in full speed. So if you tried several cat 6 cables 10 m and
> less, which are working between other systems, I don't think(!) the cable is
> of interest here... 

I don't think so, either.  When you use a short patch cable like 50 or 25cm
there could be issues because those can be of really poor quality; or when you
have 50--100 meters of a quality that works fine up to 30 meters, you might see
transmission errors and delays in the connection.  The shorter cables are
usually fine unless you have that doesn't work at all, but that's easy to figure
out.  Ethernet is remarkably robust, at least with 1GB.

I think that the network card works fine and that the mainboard is having some
issue that somehow sometimes prevents everything from being transmitted through
that card.  I'll find out if the cards works once some parts I'm waiting on have
arrived.  (I could pull the SAS controllers but without them the server is
rather useless because the disks won't be connected ...)


Reply to: