Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
Welcome to our new datacenter. The migration is still not over, but we try to bring up the service to the best we can. There are some parts not working yet (shared runners, previous job logs, previous job artifacts, ... ) but we try to do our best.
We do not guarantee data while the migration is not over, please consider this as read-only
That was wrong. The issue seems might be severe and in both cases happens because
set_fb_on_crtc function in test doesn't get a correct mode, then tries to create fb with all params set to 0, causing above mentioned assertion:
igt_fb-DEBUG: igt_create_fb_with_bo_size(width=0, height=0, format=XR24(0x34325258), modifier=0x0, size=0)
(kms_cursor_crc:1512) igt_kms-CRITICAL: Test assertion failure function kmstest_dumb_create, file ../lib/igt_kms.c:820:
In both cases this happens after probe fails for that connector:
`<7>`[ 30.889091] [drm:intel_dp_detect [i915]] [CONNECTOR:95:DP-2]
`<7>`[ 30.921069] [drm:drm_dp_dpcd_access] Too many retries, giving up. First error: -5
`<7>`[ 30.921079] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:95:DP-2] status updated from connected to disconnected
`<7>`[ 30.921169] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:95:DP-2] disconnected
`<7>`[ 30.921598] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:100:HDMI-A-1]
Also this could be related to this bug I got today:
With the help of Chamelium, I can now easily reproduce this anytime and currently the issue consists of two separate issues:
There seems to be some hardware bouncing involved for hpd pins, like very display goind to unplug and plug in a very short time. The kernel seems to not able filter those as those events are not exceeding the required threshold for irq storm detection in a fixed period of time, i.e those anyway get processed like connector going to disconnected and/or connected state quickly.
2) Sometimes connector goes to disconnected state in "unlucky" time, when igt does refresh the output, because currently it refreshes the outputs periodically in igt_output_pipe_select, during that time kernel manages to return some kind of garbage mode, containing all 0, which is then saved by igt and used during framebuffer creation => causing the asserting as drm_mode_create_dumb rejects creation of 0 size, 0 height and width buffer.
IMHO this should have fixes both in kernel(against small very short hpd pin bounces, not detectable by storm detection) and also in igt, as it should not refresh the outputs on the fly during test execution, but use cached version for
outputs, if output happens to be disconnected in the middle of a test, this will at least fail on commit, i.e in a controlled way.
The issue seems to be severe as it may cause userspace to crash in a similar way as IGT does. There are seems to be some issue either with the hardware or the way how we handle hpd irqs - as the display seem to sporadically dissapear causing issues if it happens in the middle of a test case. So we definitely need to investigate this further.