Bug#996008: Bug #996008: i225 NIC no longer recognized after 11.1 point release

[Salvatore Bonaccorso <carnil@debian.org>]

Hi

On Tue, Jun 07, 2022 at 04:50:09PM +0200, Diederik de Haas wrote:
> Control: reassign -1 src:linux 5.10.70-1
> Control: tag -1 moreinfo
> 
> On Sun, 10 Oct 2021 00:25:44 +0000 (UTC) TarotApprentice <tarotapprentice@yahoo.com> wrote:
> > Package: linux-image-amd64
> > Version: 5.10.0-9 (5.10.70-1)
> > 
> > Two machines (ASUS X570-P/CSM) with built-in NIC (realtek) and 
> > add-in 2.5GbE NIC (intel i225). After installing point release 11.1 the 
> > add-in NIC is no longer recognized on either machine. The built-in NIC still
> > works. Clearly it was working before the point release as it used the 
> > 2.5G NIC to do the apt upgrade.
> > 
> > Both machines were running kernel 5.10.0-8 and Bullseye prior to the upgrade.
> > Rebooting the machine using the 5.10.0-8 kernel (selecting it from grub) 
> > doesn't help - NIC enumeration fails.
> > 
> > # grep igc /var/log/messages
> > Oct 10 08:50:00 *** kernel: [    4.829780] igc 0000:04:00.0 enp4s0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
> > Oct 10 09:03:26 *** kernel: [    3.819348] igc: probe of 0000:04:00.0 failed with error -13
> > Oct 10 10:59:51 *** kernel: [    3.826878] igc: probe of 0000:04:00.0 failed with error -13
> 
> I'm inclined to think/agree that this is a kernel issue, but what is then
> confusing is that it still doesn't work with the same kernel version with which
> it previously did work. Which suggests that another update caused the failure.
> 
> The latest point release is now 11.3, so verifying whether the problem is still
> present there, with a newer 5.10 kernel, seems like a good first step.
> 
> If that's the case, a more complete output of dmesg or /var/log/messages would
> be useful.
> Also testing with a kernel from Testing/Unstable and/or Bullseye backports
> would also give useful extra information.

Do you still experience the same issues with the most recent kernel in
bullseye (5.10.149-2).

I'm inclined otherwise to close this bugreport, assuming it's not
reproducible. If it is reproducible, does the same issue shows up with
more recent kernels from unstable and/or backports?

Regards,
Salvatore