Tobias Nygren a écrit : > On Sat, 18 Nov 2023 20:14:32 +0100 > BERTRAND Joël <[email protected]> wrote: > >> Maybe something is broken in recent changes in >> src/sys/dev/pci/pci_resource.c, pcidevs_data.h or pcidevs.h. > > Since the attach function runs it does not seems to be a pcidevs problem. > pci_resource.c is only used on ARM platforms. You can find the equivalent > x86 code in pci_map.c. It has not been changed recently from what I can tell. > >> pci_mem_find: expected mem type 00000004, found 00000000 > > This error means we expected a 64-bit mem range assigned to the card > by the ACPI firmware but found a 32-bit range. It is a strange error > to get in this context because the card according to the config space > dump clearly only has a 32-bit BAR so it has to use 32-bit bus space. > We can reach that situation if the re driver incorrectly tried to map > the BAR with PCI_MAPREG_MEM_TYPE_64BIT. > > I suspect the regression originates with an acpica update and some > firmware bug might be a prerequisite to trigger it. > > You'll need to figure out why the expected mem type check fires.
Unfortunately, I cannot quickly test on this server and I don't have
other server in the same configuration. I will test as soon as possible,
but I have to poweroff all diskless workstations on LAN side (that run
complex simulations).
> A good place to start digging is to dissect this code and find
> out what the value retured by pci_mapreg_type is:
> https://github.com/NetBSD/src/blob/d7465f61f231e4328d26a5628c5ccb266f168f3a/sys/dev/pci/if_re_pci.c#L210
>
> Since you mentioned you have lots of other network adapters it might
> also be that the system has ran out of 32-bit bus space and
> is attempting to use 64-bit as a last resort.
Strange. -10-beta ran fine in the same configuration: wm[0-4], re0,
bridge0, lagg0, npflog0.
Best regards,
JB
signature.asc
Description: OpenPGP digital signature
