Skip to content

[BUG]ADLP firmware boot delayed by i915 issue (failure in check-sof-logger) #3042

Closed

Description

@XiaoyunWu6666

description
on ADLP_RVP_SDW and ADLP_RVP_HDA check-sof-logger failed with logger.error showing "error: Unable to open version file /sys/kernel/debug/sof/fw_version: No such file or directory" which may indicate slow/incomplete firmware boot.

And this failure leads to two FAIL/TIMEOUT in following 2 testcases , eg.
when check-alsabat-headset-playback

ALSA lib pcm_hw.c:1829:(_snd_pcm_hw_open) Invalid value for card
aplay: main:830: audio open error: No such device

when check playback all formats

2021-07-13 21:26:34 UTC [REMOTE_INFO] No SOF sound card found, exporting pipeline parameters from proc file system
error: Unable to open version file /sys/kernel/debug/sof/fw_version: No such file or directory

Something weird is long time to get suspend after ,check-sof-logger failed
after executing check-sof-logger , I got a 'fail' and then I tried 'cat /sys/bus/pci/devices/0000:00:1f.3/power/runtime_status' over and over again .
I got 'active' and then eventually got 'suspend' at the time which is actually 50 seconds after check-sof-logger failed. (You can see a 50 seconds' gap in the following picture)
image

I think after check-sof-logger testcase failed , there should be nothing using audio ,right ? So taking so much time to get suspend looks weird (However I am not quite sure whether this has something to do with 'no SOF sound card found' log in check-playback-all-formats testcase)

Activity

  1. XiaoyunWu6666 commented on Jul 14, 2021

    @XiaoyunWu6666
    Author

    BTW , reloading driver in check-sof-logger.sh is for getting logs from BYT ,right? For those platforms which can provide wanted logs, we can skip driver reloading maybe .

  2. libinyang commented on Jul 14, 2021

    @libinyang

    This bug should be related to the i915 probe taking a long time.

  3. XiaoyunWu6666 commented on Jul 14, 2021

    @XiaoyunWu6666
    Author

    @marc-hb hi marc , let's discuss about it here .
    Since check the non-stale logs as well as restarting the firmware is necessary , shall we give ADLP_RVP_SDW / ADLP_RVP_HDA more time to complete the firmware boot?
    These two platforms can reboot firmware successfully , they just need more time

  4. changed the title [-][BUG]after check-sof-logger failed ADLP_RVP_HDA and ADLP_RVP_SDW cannot suspend after over 30seconds[/-] [+][BUG] ADLP firmware boot delayed by i915 issue (failure in check-sof-logger)[/+] on Jul 14, 2021
  5. marc-hb commented on Jul 14, 2021

    @marc-hb
    Collaborator

    This bug should be related to the i915 probe taking a long time.

    Thanks, I renamed this bug.

    Since check the non-stale logs as well as restarting the firmware is necessary , shall we give ADLP_RVP_SDW / ADLP_RVP_HDA more time to complete the firmware boot?

    I'm just going to temporarily skip the check-sof-logger test on these systems, it will be more visible with less risk to forget to restore the test later.

  6. changed the title [-][BUG] ADLP firmware boot delayed by i915 issue (failure in check-sof-logger)[/-] [+][BUG]check-sof-logger failed on ADLP_RVP_HDA and ADLP_RVP_SDW because of i915[/+] on Jul 15, 2021
  7. added
    bugSomething isn't working
    i915i915 related issue
    P2Critical bugs or normal features
    on Jul 15, 2021
  8. changed the title [-][BUG]check-sof-logger failed on ADLP_RVP_HDA and ADLP_RVP_SDW because of i915[/-] [+][BUG]ADLP firmware boot delayed by i915 issue (failure in check-sof-logger)[/+] on Jul 15, 2021
  9. marc-hb commented on Jul 15, 2021

    @marc-hb
    Collaborator

    In 5288?model=ADLP_RVP_HDA&testcase=check-sof-logger the same test passed! This was on 2021-07-15 02:10:50 UTC and sh-adlp-rvp-hda-01.sh.intel.com at with SOF commit 0fa9f7d and linux kernel commit 9b277b8

    In the 9 minutes older 5285?model=ADLP_RVP_HDA&testcase=check-sof-logger it failed as described above and sh-adlp-rvp-hda-02.sh.intel.com and on sh-adlp-rvp-sdw-03 with the SAME SOF commit 0fa9f7d and kernel commit 9b277b8!

    In the same runs the test passed on other systems like sh-adlp-rvp-nocodec-02 (5285) or sh-adls-rvp-hda-04 (5285) or sh-adls-rvp-hda-05 (5288)

    EDIT: more failure examples listed in (unrelated) thesofproject/sof#4333

    This bug should be related to the i915 probe taking a long time.

    Does this happen randomly? Or is it happening only on certain units? @plbossart , Is it possible to see this long probe time in journalctl -b and if yes how?

    I'm just going to temporarily skip the check-sof-logger test on these systems, it will be more visible with less risk to forget to restore the test later.

    I submitted this in thesofproject/sof-test#741 but I'm closing it because if this bug is intermittent then we first want to know how frequent it is.

  10. plbossart commented on Jul 15, 2021

    @plbossart
    Member

    Does this happen randomly? Or is it happening only on certain units? @plbossart , Is it possible to see this long probe time in journalctl -b and if yes how?

    @marc-hb The only indication that the probe workqueue finished is this dynamic debug log:

    dev_dbg(dev, "Completing SOF PCI probe");
    
  11. marc-hb commented on Jul 15, 2021

    @marc-hb
    Collaborator

    Thanks @plbossart. I took a closer look at the logs on sh-adlp-rvp-hda-02 and it does look indeed like an intermittent, display related issue. I'm copying two extracts from the logs below. The first one is from a successful firmware load, the second log is when the firmware failed to fully load and this happened only minutes later on the same system without any reboot in between.

    Note there are other, earlier differences before the Completing SOF PCI probe message. Any insight?

    Successful log

    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: FW Poll Status: reg[0x160]=0x140000 successful
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware download successful, booting...
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc rx: 0x70000000: FW_READY
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc: DSP is ready 0x70000000 offset 0x81000
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware info: version 1:8:0-0fa9f
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware: ABI 3:19:0 Kernel ABI 3:18:0
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: warn: FW ABI is more recent than kernel
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware debug build 65535 on dtermin.-fwready. - options:
                                                GDB: disabled
                                                lock debug: disabled
                                                lock vdebug: disabled
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3:  mailbox upstream 0x81000 - size 0x1000
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3:  mailbox downstream 0xa0000 - size 0x2000
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3:  stream region 0xc1000 - size 0x1000
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3:  debug region 0xc0000 - size 0x800
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc rx done: 0x70000000: FW_READY
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: firmware boot complete
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Debug PCIR: 00000000 at  00000048
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Debug PCIW: 00000002 at  00000048
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Debug PCIR: 00000004 at  00000044
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Debug PCIW: 00000000 at  00000044
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: generating page table for 00000000880061c1 size 0x10000 pages 16
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: dma_trace_pages: 16
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: FW Poll Status: reg[0x80]=0x40000 successful
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: FW Poll Status: reg[0x80]=0x40000 successful
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: period_bytes:0x0
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: periods:1
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: stream_tag: 1
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx: 0x90030000: GLB_TRACE_MSG
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx succeeded: 0x90030000: GLB_TRACE_MSG
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: FW Poll Status: reg[0x80]=0x14001e successful
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: created machine skl_hda_dsp_generic
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Completing SOF PCI probe
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: skl_hda_dsp_generic skl_hda_dsp_generic: skl_hda_audio_probe: entry
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: skl_hda_dsp_generic skl_hda_dsp_generic: skl_hda_add_dai_link: dai link name - iDisp1
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: skl_hda_dsp_generic skl_hda_dsp_generic: skl_hda_add_dai_link: dai link name - iDisp2
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: skl_hda_dsp_generic skl_hda_dsp_generic: skl_hda_add_dai_link: dai link name - iDisp3
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: skl_hda_dsp_generic skl_hda_dsp_generic: skl_hda_add_dai_link: dai link name - Analog Playback and Capture
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: skl_hda_dsp_generic skl_hda_dsp_generic: skl_hda_add_dai_link: dai link name - Digital Playback and Capture
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: skl_hda_dsp_generic skl_hda_dsp_generic: skl_hda_add_dai_link: dai link name - dmic01
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: skl_hda_dsp_generic skl_hda_dsp_generic: skl_hda_add_dai_link: dai link name - dmic16k
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: loading topology:intel/sof-tplg/sof-hda-generic.tplg
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Topology: ABI 3:19:0 Kernel ABI 3:18:0
    Jul 15 02:03:28 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: warn: topology ABI is more recent than kernel
    

    Failing kernel log (no SOF log because the firmware didn't fully boot)

    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: FW Poll Status: reg[0x160]=0x140000 successful
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware download successful, booting...
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc rx: 0x70000000: FW_READY
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc: DSP is ready 0x70000000 offset 0x81000
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc rx done: 0x70000000: FW_READY
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: firmware boot complete
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Debug PCIR: 00000000 at  00000048
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Debug PCIW: 00000002 at  00000048
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Debug PCIR: 00000004 at  00000044
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Debug PCIW: 00000000 at  00000044
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: FW Poll Status: reg[0x80]=0x40000 successful
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: FW Poll Status: reg[0x80]=0x40000 successful
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: period_bytes:0x0
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: periods:1
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: stream_tag: 1
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx: 0x90030000: GLB_TRACE_MSG
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx succeeded: 0x90030000: GLB_TRACE_MSG
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: FW Poll Status: reg[0x80]=0x2014001e successful
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx: 0x40020000: GLB_PM_MSG: CTX_RESTORE
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx succeeded: 0x40020000: GLB_PM_MSG: CTX_RESTORE
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx: 0x40010000: GLB_PM_MSG: CTX_SAVE
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx succeeded: 0x40010000: GLB_PM_MSG: CTX_SAVE
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: FW Poll Status: reg[0x80]=0x20140000 successful
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 acpid[496]: input device has been disconnected, fd 10
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 acpid[496]: input device has been disconnected, fd 9
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 systemd[1]: Stopped target Sound Card.
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: FW Poll Status: reg[0x4]=0x9010f0f successful
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: FW Poll Status: reg[0x4]=0xf0f successful
    Jul 15 02:04:32 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: DSP core(s) enabled? 0 : core_mask 1
    
     < note the 2 seconds gap >
    
    Jul 15 02:04:34 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: PCI DSP detected
    Jul 15 02:04:34 sh-adlp-rvp-hda-02 kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100
    
     < test times out after 10s >
    
    Jul 15 02:04:45 sh-adlp-rvp-hda-02 systemd-logind[543]: Session 24 logged out. Waiting for processes to exit.
    Jul 15 02:04:45 sh-adlp-rvp-hda-02 systemd-logind[543]: Removed session 24.
    
  12. plbossart commented on Jul 15, 2021

    @plbossart
    Member

    any idea what this is @marc-hb ?

    Jul 15 02:04:32 sh-adlp-rvp-hda-02 systemd[1]: Stopped target Sound Card.
    

    This seems to come even before the card is created?

  13. marc-hb commented on Jul 15, 2021

    @marc-hb
    Collaborator

    Not sure in this particular case but in general this is just systemd monitoring /proc/asound/cards for dependency tracking purposes: other services may require a soundcard - like pulseaudio for instance. Even when disabling pulseaudio systemd still keeps track.

    Very easy to see it for yourself:

    sof-test/tools/kmod/sof_insert.sh
    journalctl -f # in a different terminal
    Jul 15 16:17:44 up2 systemd[1]: Reached target Sound Card.
    
    sof-test/tools/kmod/sof_remove.sh
    Jul 15 16:18:05 up2 systemd[527]: Stopped target Sound Card.
    
    systemctl show sound.target
    
     => FragmentPath=/lib/systemd/system/sound.target
    
    man systemd.special
    
           sound.target
               This target is started automatically as soon as a sound card is plugged in or becomes available at boot.
    
               This may be used to pull in audio management daemons dynamically when audio hardware is found.
    
  14. XiaoyunWu6666 commented on Jul 23, 2021

    @XiaoyunWu6666
    Author

    @kv2019i @marc-hb @libinyang
    Adding new PCI IDs manually to i915.force_probe has been a regular step on any bleeding edge platform (otherwise i915 refuses to load on these)

    On ADL DUTs , add following contents can help.

    cat /etc/modprobe.d/i915.conf  (if there is no i915.conf , add it by yourself)
    options i915 force_probe=*

    I have modified i915.conf on all ADLP_RVP_SDW ADLP_RVP_HDA DUTs, they all pass check-sof-logger testcase now.

  15. marc-hb commented on Jul 23, 2021

    @marc-hb
    Collaborator

    @kv2019i can you confirm that i915.force_probe is helpful only when i915 REFUSES to load AT ALL? Not when it is flaky like here.

    I have modified i915.conf on all ADLP_RVP_SDW ADLP_RVP_HDA DUTs, they all pass check-sof-logger testcase now.

    This test was failing only from time to time, so maybe you just got lucky.

  16. XiaoyunWu6666 commented on Jul 23, 2021

    @XiaoyunWu6666
    Author

    @kv2019i can you confirm that i915.force_probe is helpful only when i915 REFUSES to load AT ALL? Not when it is flaky like here.

    I have modified i915.conf on all ADLP_RVP_SDW ADLP_RVP_HDA DUTs, they all pass check-sof-logger testcase now.

    This test was failing only from time to time, so maybe you just got lucky.

    Yes so I will track how they perform in daily tests

  17. kv2019i commented on Jul 23, 2021

    @kv2019i
    Collaborator

    @marc-hb Correct, on platforms where i915.force_probe is needed, driver probe will fail every time if the setting is not set.

    It is possible the i915 negotiation failed earlier on some occasions (but i915 was still not functional), but definitely now with recent upstream merge and the force_probe setting, expecation is that at least i915 is no longer causing delays to the probe.

  18. marc-hb commented on Jul 23, 2021

    @marc-hb
    Collaborator

    Thanks @kv2019i!
    @XiaoyunWu6666, at your leisure please remove the i915.force_probe you just added. I don't think they can cause any harm but they can cause confusion.

  19. kv2019i commented on Jul 23, 2021

    @kv2019i
    Collaborator

    @marc-hb @XiaoyunWu6666 no, please keep the i915.force_probe . It's still needed. i915 won't load on new platforms without this option.

  20. marc-hb commented on Jul 23, 2021

    @marc-hb
    Collaborator

    i915 won't load on new platforms without this option.

    @XiaoyunWu6666 changed it only on systems where i915 was already loading.

  21. XiaoyunWu6666 commented on Jul 27, 2021

    @XiaoyunWu6666
    Author

    FYI, I changed that on ADLP_RVP_SDW and ADLP_RVP_HDA DUTs.
    in inner daily-ADL 5495 5635 they worked well(ADL models have been added back to daily testplan)

  22. XiaoyunWu6666 commented on Aug 2, 2021

    @XiaoyunWu6666
    Author

    HDMI1 worked well on ADLP_RVP_SDW (-Dhw:0,5 )and ADLP_RVP_HDA(-Dhw:0,3) with latest sof-dev and /etc/modprobe.d/i915.conf

    options i915 force_probe=*
    

    hi , @kv2019i , shall we close this ? :) thanks

  23. kv2019i commented on Aug 5, 2021

    @kv2019i
    Collaborator

    Excellent @XiaoyunWu6666 , that sounds good now, let's close.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

ADLApplies to Alder Lake platformP2Critical bugs or normal featuresbugSomething isn't workingi915i915 related issue

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions