+81
−50
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
When I thought it was finally defeated, it came back with vengeance. The failure cases are ever more convoluted. Now there is a single combination which fails boot probing - MCP5x + Intel SSD and there are two hotplug failure reports on different flavors where softreset fails to bring up the device. Through the many bug reports after the switch to hardreset, the following patterns emerged. - Softreset during boot always works. - Hardreset during boot sometimes fails to bring up the link on certain comibnations and device signature acquisition is unreliable. - Hardreset is often necessary after hotplug. It looks like the old behavior of preferring softreset was somehow pretty close to the working reset protocol although it could have lost a device during phy error handling by issuing hardreset. This patch implements nv_hardreset() which kicks in only for post-boot (!LOADING) device probing resets. This should be able to work around all known problem cases. This isn't perfect but given the various hardreset quirks on these controllers, I think this is as good as it can get. Tested on mcp5x (swncq), nf3 and ck804 for all both boot, warm and hot probing cases. Kudos to all the bug reporters and their painful hours with these damn controllers. ;-) Signed-off-by:Tejun Heo <tj@kernel.org> Cc: Robert Hancock <hancockr@shaw.ca> Reported-by:
David Lang <david@lang.hm> Reported-by:
Samo Vodopivec <lament.email.si@gmail.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com>
CRA Git | Maintained and supported by SUSTech CRA and CCSE