Tobias Nygren a écrit : > On Sat, 18 Nov 2023 20:14:32 +0100 > BERTRAND Joël <joel.bertrand%systella.fr@localhost> 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
Attachment:
signature.asc
Description: OpenPGP digital signature