Re: MRF kernel modules not seeing hardware

[Jukka Pietarinen via Tech-talk <tech-talk at aps.anl.gov>]

Hi Evan,

On the cPCI-EVG-300 and cPCI-EVR-300 the PCI IDs are stored in the FPGA 
firmware. To me this looks like a hardware error, tied low/open PCI 
address/data line, but I think in this case you should be seeing PCI bus 
parity errors. Is your PCI bus configured for 33 MHz operation?
Thanks,
Jukka

On 1/30/2025 6:40 AM, Daykin, Evan via Tech-talk 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 <https://urldefense.us/v3/__https://aka.ms/ 
> AAb9ysg__;!!G_uCfscf7eWS!f9BlP7yLbdRDG9pvOMrXpVBYO_Z- 
> Nu4WsAbHTNtKrsZrw9v7DX5Rw2upXCuxIwU39HUPU5vSIF7yn6KiuE79dZPF$>
> ------------------------------------------------------------------------
> *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://urldefense.us/v3/__https://github.com/epics-modules/mrfioc2/blob/master/mrmShared/linux/__;!!G_uCfscf7eWS!eIt84DuAvD8lvrBYUVeKIWW6oVOU9smlkbov6ZnNB3lGK_Onhu1nhQoj9uqGfP1xG9oQz6GTrXr5lqS3gIYLYj7N-LJoJ-g4$  
> uio_mrf.c#L41-L74 <https://urldefense.us/v3/__https://github.com/epics- 
> modules/mrfioc2/blob/master/mrmShared/linux/uio_mrf.c*L41-L74__;Iw!! 
> G_uCfscf7eWS!f9BlP7yLbdRDG9pvOMrXpVBYO_Z- 
> Nu4WsAbHTNtKrsZrw9v7DX5Rw2upXCuxIwU39HUPU5vSIF7yn6KiuLd20tPK$> 
> <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.