+1
−1
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
The PCIe specification, rev 3.0, section 2.2.8.1, contains the following implementation note: Virtual Wire Mapping for INTx Interrupts From ARI Devices The implied Device Number for an ARI Device is 0. When ARI-aware software (including BIOS and operating system) enables ARI Forwarding in the Downstream Port immediately above an ARI Device in order to access its Extended Functions, software must comprehend that the Downstream Port will use Device Number 0 for the virtual wire mappings of INTx interrupts coming from all Functions of the ARI Device. If non-ARI-aware software attempts to determine the virtual wire mappings for Extended Functions, it can come up with incorrect mappings by examining the traditional Device Number field and finding it to be non-0. We account for this in pci_swizzle_interrupt_pin(), but it looks like we miss it here, looking for a _PRT entry with a slot matching the ARI device slot number. This can cause errors like: pcieport 0000:80:03.0: can't derive routing for PCI INT B sfc 0000:82:01.1: PCI INT B: no GSI pci_dev.irq is then invalid, resulting in errors for drivers that attempt to enable INTx on the device. Fix by using slot 0 for ARI enabled devices. Signed-off-by:Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Don Dutile <ddutile@redhat.com> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CRA Git | Maintained and supported by SUSTech CRA and CCSE