+22
−18
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
The VGA arbiter does not allow devices to "own" resources that it doesn't "decode". However, it does allow devices to "lock" resources that it doesn't decode. This gets us into trouble because locking the resource goes through the same bridge routing updates regardless of whether we decode the resource. This means that when a non-decoded resource is released, the bridge is left with VGA routing enabled and locking a different device won't clear it. This happens in the following scenario: VGA device 01:00.0 (VGA1) is owned by the radeon driver, which registers a set_vga_decode function which releases legacy VGA decodes. VGA device 02:00.0 (VGA2) is any VGA device. VGA1 user locks VGA resources triggering first_use callback of set_vga_decoded, clearing "decode" and "owns" of legacy resources on VGA1. VGA1 user unlocks VGA resources. VGA2 user locks VGA resources, which skips VGA1 as conflicting as it does not "own" legacy resources, although VGA routing is still enabled for the VGA1 bridge. VGA routing is enabled on VGA2 bridge. VGA2 may or may not receive VGA transactions depending on the bus priority of VGA1 vs VGA2 bridge. To resolve this, we need to allow devices to "own" resources that they do not "decode". This way we can track bus ownership of VGA. When a device decodes VGA, it only means that we must update the command bits in cases where the conflicting device is on the same bus. Signed-off-by:Alex Williamson <alex.williamson@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
CRA Git | Maintained and supported by SUSTech CRA and CCSE