Re: MRF kernel modules not seeing hardware

[Han Lee via Tech-talk <tech-talk@aps.anl.gov>]

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@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@gmail.com>
Sent: Wednesday, January 29, 2025 11:17:30 PM
To: Han Lee <jeonglee@lbl.gov>; Di Wang <di.wang@kek.jp>; daykin@frib.msu.edu <daykin@frib.msu.edu>
Cc: EPICS tech-talk <tech-talk@aps.anl.gov>; jerzy.jamroz@ess.eu <jerzy.jamroz@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