On Wed, 2024-02-28 at 11:23 +0100, Harald Dunkel wrote: > It used to work with the same kernel. OK. > This is what we get for the new (6.5.10, Debian backports) kernel now: But that'd mean it's working - or are you saying that's a different machine? > [Tue Feb 27 09:44:51 2024] iwlwifi 0000:00:14.3: enabling device (0000 -> 0002) > [Tue Feb 27 09:44:51 2024] iwlwifi 0000:00:14.3: Detected crf-id 0x1300504, cnv-id 0x80400 wfpm id 0x80000030 > [Tue Feb 27 09:44:51 2024] iwlwifi 0000:00:14.3: PCI dev 51f1/0074, rev=0x370, rfid=0x10a100 This seems to work, has a proper PCI ID, and shows a different RF ID? You previously showed iwlwifi: No config found for PCI dev 51f1/0000, rev=0x370, rfid=0x1010c000 So I think it'd still be interesting to know this line from the system that doesn't work any more, to see if it really was _exactly_ the same, as this before and changed, or whatever happened. > > If you really have subdevice ID 0000 then something went wrong and you > > have a blank OTP (now), which seems very strange. > > > > This is an integrated NIC where part of the NIC is integrated into the > > platform, and other parts are on the companion RF (CRF), so could also > > be that the CRF module isn't seated well any more in the slot and it > > just cannot access the data properly? > > > > You mean there could be a problem with the wifi card not being plugged in > properly? We will check when my colleague is in the office. Yes, that's what I mean. Note the "wifi card" is just the CRF module in this case, much of the wifi is already built into the platform/SoC. The M.2 form factor card that you have in it isn't the PCIe device that shows up in Linux, it's just the radio module etc. So that not being connected properly might explain a situation like this, not sure though. johannes
