RE: MRF kernel modules not seeing hardware

["Daykin, Evan via Tech-talk" <tech-talk at aps.anl.gov>]

I haven’t performed any super comprehensive testing, but regardless of whatever problem my system is having to enumerate the right PCIID, it so far seems to work fine to just map the weird ID to the same cPCI-EVR-300 support.

 

I doubt this should be incorporated upstream, we can maintain a patch for our own misbehaving stuff. But in case anyone from the future stumbles on this issue, it really does seem to be this simple:

 

From: Evan Daykin <daykin at frib.msu.edu>

Date: Fri, 7 Feb 2025 15:07:59 -0500

Subject: [PATCH] Add 'support' for weird quirk where system is reporting

 cPCI-EVG/EVR-300 as <device ID & 0xFFDF>, e.g. 152c->150c

 

---

 evgMrmApp/src/evgInit.cpp    |  4 +++-

 evrMrmApp/src/drvemSetup.cpp |  6 +++++-

 mrmShared/linux/uio_mrf.c    | 10 ++++++++++

 mrmShared/src/mrmpci.h       |  3 +++

 4 files changed, 21 insertions(+), 2 deletions(-)

 

diff --git a/evgMrmApp/src/evgInit.cpp b/evgMrmApp/src/evgInit.cpp

index c271704..13cf847 100644

--- a/evgMrmApp/src/evgInit.cpp

+++ b/evgMrmApp/src/evgInit.cpp

@@ -356,6 +356,7 @@ mrmevgs[] = {

     DEVPCI_SUBDEVICE_SUBVENDOR(PCI_DEVICE_ID_PLX_9030, PCI_VENDOR_ID_PLX,PCI_SUBDEVICE_ID_MRF_PXIEVG_220, PCI_VENDOR_ID_MRF),

     DEVPCI_SUBDEVICE_SUBVENDOR(PCI_DEVICE_ID_PLX_9030, PCI_VENDOR_ID_PLX,PCI_DEVICE_ID_MRF_PXIEVG230, PCI_VENDOR_ID_MRF),

     DEVPCI_DEVICE_VENDOR(PCI_DEVICE_ID_MRF_CPCIEVG300, PCI_VENDOR_ID_MRF),

+    DEVPCI_DEVICE_VENDOR(PCI_DEVICE_ID_MRF_CPCIEVG300_WEIRD, PCI_VENDOR_ID_MRF),

     DEVPCI_SUBDEVICE_SUBVENDOR(PCI_DEVICE_ID_XILINX_DEV, PCI_VENDOR_ID_XILINX, PCI_DEVICE_ID_MRF_MTCA_EVM_300, PCI_VENDOR_ID_MRF),

     DEVPCI_END

 };

@@ -445,6 +446,7 @@ mrmEvgSetupPCI (

 #endif

             break;

         case PCI_DEVICE_ID_MRF_CPCIEVG300:

+        case PCI_DEVICE_ID_MRF_CPCIEVG300_WEIRD:

         case PCI_DEVICE_ID_XILINX_DEV:

             BAR_evg = BAR_plx;

             /* the endianness the 300 series devices w/o PLX bridge

@@ -477,7 +479,7 @@ mrmEvgSetupPCI (

 

         const evgMrm::Config *conf = &conf_pci_misc;

 

-        if(cur->id.device==PCI_DEVICE_ID_MRF_CPCIEVG300) {

+        if(cur->id.device==PCI_DEVICE_ID_MRF_CPCIEVG300 || cur->id.device==PCI_DEVICE_ID_MRF_CPCIEVG300_WEIRD) {

             conf = &conf_cpci_evg_300;

         } else switch(cur->id.sub_device) {

         case PCI_SUBDEVICE_ID_MRF_PXIEVG_220: conf = &conf_cpci_evg_220; break;

diff --git a/evrMrmApp/src/drvemSetup.cpp b/evrMrmApp/src/drvemSetup.cpp

index 39f85ac..8e7e6c8 100755

--- a/evrMrmApp/src/drvemSetup.cpp

+++ b/evrMrmApp/src/drvemSetup.cpp

@@ -75,6 +75,8 @@ static const epicsPCIID mrmevrs[] = {

                                 PCI_DEVICE_ID_MRF_EVRTG_300E, PCI_VENDOR_ID_MRF)

     /* cPCI-EVR-300 */

     ,DEVPCI_DEVICE_VENDOR(PCI_DEVICE_ID_MRF_CPCIEVR300,    PCI_VENDOR_ID_MRF)

+    /* weird cPCI-EVR-300*/

+    ,DEVPCI_DEVICE_VENDOR(PCI_DEVICE_ID_MRF_CPCIEVR300_WEIRD, PCI_VENDOR_ID_MRF)

     /* mTCA-EVR-300 */

     ,DEVPCI_SUBDEVICE_SUBVENDOR(PCI_DEVICE_ID_XILINX_DEV,    PCI_VENDOR_ID_XILINX,

                                PCI_DEVICE_ID_MRF_EVRMTCA300, PCI_VENDOR_ID_MRF)

@@ -536,7 +538,8 @@ try {

     case PCI_DEVICE_ID_MRF_PMCEVR_230: conf = &pmc_evr_230; break;

     case PCI_DEVICE_ID_MRF_PXIEVR_230: conf = &cpci_evr_230; break;

     case PCI_DEVICE_ID_MRF_EVRTG_300:  conf = &cpci_evrtg_300; break;

-    case PCI_DEVICE_ID_MRF_CPCIEVR300: conf = &cpci_evr_300; break;

+    case PCI_DEVICE_ID_MRF_CPCIEVR300:

+    case PCI_DEVICE_ID_MRF_CPCIEVR300_WEIRD: conf = &cpci_evr_300; break;

     case PCI_DEVICE_ID_MRF_EVRMTCA300:

         if (mtca_evr_model == NULL)

         {

@@ -652,6 +655,7 @@ try {

 

     case PCI_DEVICE_ID_EC_30:

     case PCI_DEVICE_ID_MRF_CPCIEVR300:

+    case PCI_DEVICE_ID_MRF_CPCIEVR300_WEIRD:

     case PCI_DEVICE_ID_XILINX_DEV:

         /* the endianness the 300 series devices w/o PLX bridge

          * is a little tricky to setup.  byte order swapping is controlled

diff --git a/mrmShared/linux/uio_mrf.c b/mrmShared/linux/uio_mrf.c

index dff7652..5bd7ba5 100644

--- a/mrmShared/linux/uio_mrf.c

+++ b/mrmShared/linux/uio_mrf.c

@@ -70,6 +70,9 @@ MODULE_PARM_DESC(use_msi, "Use MSI if present (default 1, yes)");

 #define PCI_DEVICE_ID_MRF_CPCI_EVG_300      0x252c

 /* cPCI-EVR-300 */

 #define PCI_DEVICE_ID_MRF_CPCI_EVR_300      0x152c

+/* cPCI-EVR-300, according to our weird CPU card*/

+#define PCI_DEVICE_ID_MRF_CPCI_EVR_300_WEIRD    0x150c

+

 /* mTCA-EVR-300 */

 #define PCI_DEVICE_ID_MRF_EVRMTCA300  0x132c

 

@@ -754,6 +757,13 @@ static struct pci_device_id mrf_pci_ids[] = {

         .subdevice =    PCI_DEVICE_ID_MRF_CPCI_EVR_300,

         .driver_data =  0x14,

     },

+    {

+        .vendor =       PCI_VENDOR_ID_MRF,

+        .device =       PCI_DEVICE_ID_MRF_CPCI_EVR_300_WEIRD,

+        .subvendor =    PCI_SUBVENDOR_ID_MRF,

+        .subdevice =    PCI_DEVICE_ID_MRF_CPCI_EVR_300_WEIRD,

+        .driver_data =  0x14,

+    },

     {

         .vendor =       PCI_VENDOR_ID_XILINX,

         .device =       PCI_DEVICE_ID_XILINX_DEV,

diff --git a/mrmShared/src/mrmpci.h b/mrmShared/src/mrmpci.h

index 76bec23..3d740b4 100644

--- a/mrmShared/src/mrmpci.h

+++ b/mrmShared/src/mrmpci.h

@@ -49,4 +49,7 @@

 #define PCI_DEVICE_ID_MRF_CPCIEVG300 0x252c

 #define PCI_DEVICE_ID_MRF_CPCIEVR300 0x152c

 

+#define PCI_DEVICE_ID_MRF_CPCIEVG300_WEIRD 0x250c

+#define PCI_DEVICE_ID_MRF_CPCIEVR300_WEIRD 0x150c

+

 #endif /* MRMPCI_H */

--

2.39.5

 

 

 

From: Daykin, Evan
Sent: Thursday, January 30, 2025 10:32 AM
To: 'Han Lee' <jeonglee at lbl.gov>
Cc: Michael Davidsaver <mdavidsaver at gmail.com>; Di Wang <di.wang at kek.jp>; EPICS tech-talk <tech-talk at aps.anl.gov>; jerzy.jamroz at ess.eu
Subject: RE: MRF kernel modules not seeing hardware

 

Hi Han,

 

These are cPCI-EVG-300 and cPCI-EVR-300, which “should” be supported, and indeed they are with our other CPU cards that are cooperating. They’re reporting different IDs to different hardware. At this time I don’t think anything needs to be added, rather that there’s some hairy PCI bus configuration issue.

 

-Evan

 

From: Han Lee <jeonglee at lbl.gov>
Sent: Wednesday, January 29, 2025 11:54 PM
To: Daykin, Evan <daykin at frib.msu.edu>
Cc: Michael Davidsaver <mdavidsaver at gmail.com>; Di Wang <di.wang at kek.jp>; EPICS tech-talk <tech-talk at aps.anl.gov>; jerzy.jamroz at ess.eu
Subject: Re: MRF kernel modules not seeing hardware

 

[EXTERNAL] This email originated from outside of FRIB

Hi Evan,

 

The MRF kernel driver code defines the supported MRF cards defined in

https://github.com/epics-modules/mrfioc2/blob/ba5e9c42594dcb3cb8421f3bb7e5015b5404df97/mrmShared/linux/uio_mrf.c#L54

as Di mentioned.

 

The hardware support is the same as +5 years ago in the mrf kernel support, when I left the MTCA-verse at ESS.

 

So my question is now, what MRF hardwares do you use currently?

 

Since I don't see your PCI ID in the kernel source and my pci.ids file, we need to understand what hardware you have now.

If this is the case, we can modify the mrfioc2 kernel driver to support your hardware.

 

1. In most cases, mrfioc2 will work, I guess your hardware is strongly based on the MTCA MRF product lines.

2. In the worst case scenario, someone has to test the hardware and update the device support within the mrfioc2 kernel.

 

ESS may have the latest kernel driver for your hardware, I guess. Jerzy will confirm it.

 

Best,

Han

 

 

On Wed, Jan 29, 2025 at 8:40 PM Daykin, Evan <daykin at frib.msu.edu> wrote:

Are the PCI IDs supposed to be intrinsic/stored on the card? The odd thing I'm seeing is that the *same* card on the same backplane has a different ID depending on which CPU I use. A known "good" CPU card and kernel module install is seeing 152, the "bad" is seeing 150. 

 

Get Outlook for Android

---

From: Michael Davidsaver <mdavidsaver at gmail.com>
Sent: Wednesday, January 29, 2025 11:17:30 PM
To: Han Lee <jeonglee at lbl.gov>; Di Wang <di.wang at kek.jp>; daykin at frib.msu.edu <daykin at frib.msu.edu>
Cc: EPICS tech-talk <tech-talk at aps.anl.gov>; jerzy.jamroz at ess.eu <jerzy.jamroz at ess.eu>
Subject: Re: MRF kernel modules not seeing hardware

 

[EXTERNAL] This email originated from outside of FRIB
On 1/29/25 18:52, Han Lee via Tech-talk wrote:
> FYI, The supported PCI IDs
> https://github.com/epics-modules/mrfioc2/blob/master/mrmShared/linux/uio_mrf.c#L41-L74 <https ://github.com/epics-modules/mrfioc2/blob/master/mrmShared/linux/uio_mrf.c#L41-L74>


I think the essential point has already been made, when a PCI device is enumerated,
but no loaded driver associates, this is almost always the result of a PCI ID mis-match.

fyi. the 'modinfo' utility can dump the match/alias list from the meta-data stored
in a compiled kernel module.

> $ modinfo mrf.ko
...
> alias:          pci:v000010EEd00007011sv00001A3Esd0000232Cbc*sc*i*
> alias:          pci:v000010EEd00007011sv00001A3Esd0000132Cbc*sc*i*
> alias:          pci:v00001A3Ed0000152Csv00001A3Esd0000152Cbc*sc*i*
> alias:          pci:v00001A3Ed0000252Csv00001A3Esd0000252Cbc*sc*i*
> alias:          pci:v000010EEd00007011sv00001A3Esd0000172Cbc*sc*i*
> alias:          pci:v00001204d0000EC30sv00001A3Esd0000172Cbc*sc*i*
> alias:          pci:v000010B5d00009056sv00001A3Esd0000192Cbc*sc*i*
> alias:          pci:v000010B5d00009030sv00001A3Esd000011E6bc*sc*i*
> alias:          pci:v000010B5d00009030sv00001A3Esd000020E6bc*sc*i*
> alias:          pci:v000010B5d00009030sv00001A3Esd000020DCbc*sc*i*
> alias:          pci:v000010B5d00009030sv00001A3Esd000010E6bc*sc*i*
...

These lines decode as key-value pairs with wildcards for some values.

eg. "pci:v000010B5d00009030sv00001A3Esd000010E6bc*sc*i*"

will match a PCI vendor:device 0x10ee:0x9030 sub-vendor:sub-device 0x1a3e:0x10e6

"bc*" and "sc*" match any class/sub-class

"i*" matches any interface.  Although I'm not sure what "interface" means in this context.

--

Jeong Han Lee, Dr.rer.nat.

Lawrence Berkeley National Laboratory

https://orcid.org/0000-0002-1699-2660