Samuel Thibault, le dim. 06 sept. 2020 15:17:51 +0200, a ecrit: > Samuel Thibault, le dim. 06 sept. 2020 15:14:27 +0200, a ecrit: > > Thanks for working on this! > > > > I have uploaded libpciaccess_0.16-1+hurd.5 with the latest upstream > > version. > > One issue remains, however: Xorg's vesa driver produces > > [1669282.478] (II) VESA(0): initializing int10 > [1669282.478] (EE) VESA(0): Cannot read int vect > > which comes from hw/xfree86/int10/generic.c xf86ExtendedInitInt10: > > if (!sysMem) > pci_device_map_legacy(pInt->dev, V_BIOS, BIOS_SIZE + SYS_BIOS - > V_BIOS, > PCI_DEV_MAP_FLAG_WRITABLE, &sysMem); > INTPriv(pInt)->sysMem = sysMem; > > if (!readIntVec(pInt->dev, base, LOW_PAGE_SIZE)) { > xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "Cannot read int vect\n"); > goto error1; > } > > where > > #define V_BIOS 0xC0000 > #define BIOS_SIZE 0x10000 > #define SYS_BIOS 0xF0000 > > static Bool > readIntVec(struct pci_device *dev, unsigned char *buf, int len) > { > void *map; > > if (pci_device_map_legacy(dev, 0, len, 0, &map)) > return FALSE; > > memcpy(buf, map, len); > pci_device_unmap_legacy(dev, map, len); > > return TRUE; > } > > Linux uses its own implementation, so it could very well be a bug in the > code above, please check according to what you have understood of the > libpciaccess mapping practices.
(or possibly it's simply a pci-arbiter bug?) Samuel