Samuel Thibault, le dim. 03 nov. 2019 18:58:57 +0100, a ecrit:
> Joan Lledó via Bug reports for the GNU Hurd, le dim. 03 nov. 2019 18:49:08
> +0100, a ecrit:
> > Take a look at hurd_pci.c:452 [1]
> >
> > /* If we can open pci cfg io ports on hurd,
> > * we are the arbiter, therefore try x86 method first */
> > err = pci_system_x86_create();
>
> Uh, that is not what we have in the current Debian package. Somehow that
> version didn't get submitted here, only upstream. That is why there was
> a misunderstanding.
Ok, with that change, the pci-arbiter cleanup change does let hurd boot.
I'm however seeing lspci successfully using the x86 method, and thus not
use the pci arbiter, that's not what we want :)
(it seems the PCI port exclusion does not actually work, is the PCI
arbiter really keeping them reserved in GNU Mach?)
So I guess that it boots just because libpciaccess succeeds to use the
x86 method, whether the pci arbiter is there or not.
I tried the hack I mentioned previously (attached), to properly detect
that we are the PCI arbiter. Now my system boots, but that's because
netdde crashes instead of just hanging. It looks like it does not manage
to use the PCI arbiter.
Samuel
Use netfs_server_name to detect whether we are the PCI arbiter.
Index: libpciaccess-0.14/src/hurd_pci.c
===================================================================
--- libpciaccess-0.14.orig/src/hurd_pci.c
+++ libpciaccess-0.14/src/hurd_pci.c
@@ -447,11 +447,14 @@ pci_system_hurd_create(void)
size_t ndevs;
mach_port_t pci_server_port;
- /* If we can open pci cfg io ports on hurd,
- * we are the arbiter, therefore try x86 method first */
- err = pci_system_x86_create();
- if (!err)
- return 0;
+ extern char *netfs_server_name;
+#pragma weak netfs_server_name
+ if (netfs_server_name && !strcmp(netfs_server_name, "pci-arbiter")) {
+ /* We are a PCI arbiter, try the x86 way */
+ err = pci_system_x86_create();
+ if (!err)
+ return 0;
+ }
pci_sys_hurd = calloc(1, sizeof(struct pci_system_hurd));
if (pci_sys_hurd == NULL) {
