From: Jacob Keller <jacob.e.keller@intel.com>
To: Jocelyn Falempe <jfalempe@redhat.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
"airlied@redhat.com" <airlied@redhat.com>
Cc: <dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Pasi Vaananen <pvaanane@redhat.com>
Subject: further issues with MGA G200 graphics chipset
Date: Wed, 22 Apr 2026 16:55:06 -0700 [thread overview]
Message-ID: <76aba88d-ec23-4b3c-ad91-83face0c3e94@intel.com> (raw)
Hello,
You may recall the issues I recently reported and submitted a fix for in
the mgag200 DRM driver from [1].
[1]:
https://lore.kernel.org/all/20260202-jk-mgag200-fix-bad-udelay-v2-1-ce1e9665987d@intel.com/
I recently have been running into another issue with the mgag200
graphics driver on a similar platform. I noticed occasional spikes where
Tx timestamps from the ice driver were delayed, very similar behavior to
what was going on with the original bug report. However, this was on a
system running v6.12.76, which contains my MGA G200 usleep fix.
I analyzed the data with perf and have discovered what looks like
another issue where the mgag200 polling routine is causing us issues.
Here's a perf report which captures the cycles samples between the start
of a Tx timestamp request and the point where we report it to the stack:
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] ret_from_fork_asm
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] ret_from_fork
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] kthread
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] worker_thread
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] process_one_work
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] output_poll_execute
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] drm_client_dev_hotplug
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] drm_fbdev_shmem_client_hotplug
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] drm_fb_helper_hotplug_event
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] drm_client_modeset_probe
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] drm_helper_probe_single_connector_modes
> + 89.87% 0.00% kworker/65:1-ev [mgag200] [k] mgag200_vga_bmc_connector_helper_get_modes
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] drm_connector_helper_get_modes
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] drm_edid_read
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] drm_edid_read_custom
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] _drm_do_get_edid
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] edid_block_read
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] drm_do_probe_ddc_edid
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] i2c_transfer
> + 89.87% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] __i2c_transfer
> + 89.87% 0.00% kworker/65:1-ev [i2c_algo_bit] [k] bit_xfer
> - 59.65% 59.65% kworker/65:1-ev [kernel.kallsyms] [k] delay_halt_tpause
> ret_from_fork_asm
> ret_from_fork
> kthread
> worker_thread
> process_one_work
> output_poll_execute
> drm_client_dev_hotplug
> drm_fbdev_shmem_client_hotplug
> drm_fb_helper_hotplug_event
> drm_client_modeset_probe
> drm_helper_probe_single_connector_modes
> mgag200_vga_bmc_connector_helper_get_modes
> drm_connector_helper_get_modes
> drm_edid_read
> drm_edid_read_custom
> _drm_do_get_edid
> edid_block_read
> drm_do_probe_ddc_edid
> i2c_transfer
> __i2c_transfer
> + bit_xfer
> + 59.65% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] __udelay
> + 59.65% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] __const_udelay
> + 51.11% 0.00% kworker/65:1-ev [i2c_algo_bit] [k] sclhi
> + 30.22% 30.22% kworker/65:1-ev [kernel.kallsyms] [k] ioread8
> + 7.30% 0.00% kworker/65:1-ev [kernel.kallsyms] [k] delay_halt
> + 7.30% 0.00% kworker/65:1-ev [i2c_algo_bit] [k] acknak
> + 7.29% 0.00% kworker/65:1-ev [mgag200] [k] mgag200_ddc_algo_bit_data_setscl
> + 5.02% 0.00% swapper [kernel.kallsyms] [k] secondary_startup_64
> + 5.02% 0.00% swapper [kernel.kallsyms] [k] start_secondary
> + 5.02% 0.00% swapper [kernel.kallsyms] [k] cpu_startup_entry
> + 5.02% 0.00% swapper [kernel.kallsyms] [k] do_idle
> + 3.60% 0.00% swapper [kernel.kallsyms] [k] call_cpuidle
> + 3.60% 0.00% swapper [kernel.kallsyms] [k] cpuidle_enter
> + 3.53% 0.00% swapper [kernel.kallsyms] [k] cpuidle_enter_state
> + 2.57% 0.00% kworker/65:1-ev [mgag200] [k] mgag200_ddc_algo_bit_data_setsda
> + 2.14% 0.00% perf [unknown] [k] 0xffffffffffffffff
> + 2.14% 0.00% perf perf [.] __cmd_record.constprop.0
> + 2.14% 0.00% perf [kernel.kallsyms] [k] entry_SYSCALL_64
> + 2.14% 0.00% perf [kernel.kallsyms] [k] do_syscall_64
> + 2.14% 0.00% perf [kernel.kallsyms] [k] x64_sys_call
> + 2.06% 2.06% swapper [kernel.kallsyms] [k] intel_idle
> + 1.31% 0.42% perf [kernel.kallsyms] [k] do_sys_poll
> + 1.31% 0.00% perf perf [.] fdarray__poll
> + 1.31% 0.00% perf libc.so.6 [.] __poll
> + 1.31% 0.00% perf [kernel.kallsyms] [k] __x64_sys_poll
> + 1.06% 0.00% systemd-journal systemd-journald [.] 0x00005d6bb7cb3f64
> + 1.06% 0.00% systemd-journal libc.so.6 [.] __libc_start_main
> + 1.06% 0.00% systemd-journal libc.so.6 [.] 0x00007d6ce3a2a1c9
> + 1.06% 0.00% systemd-journal systemd-journald [.] 0x00005d6bb7cb389e
> + 1.06% 0.00% systemd-journal libsystemd-shared-255.so [.] sd_event_run
> + 1.06% 0.00% systemd-journal libsystemd-shared-255.so [.] sd_event_dispatch
> + 1.06% 0.00% systemd-journal libsystemd-shared-255.so [.] 0x00007d6ce409d413
> + 1.00% 0.00% kworker/65:1-ev [i2c_algo_bit] [k] i2c_stop
> + 0.83% 0.00% perf [kernel.kallsyms] [k] perf_poll
> + 0.83% 0.00% perf perf [.] record__mmap_read_evlist
>
As you can see, in this case we are spending +60% of the cycles in
delay_halt_tpause which is part of the bit_xfer function for
implementing i2c.
I also occasionally see these messages coming on dmesg:
> Apr 20 23:14:44 1762811 kernel: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND
> Apr 20 23:14:44 1762811 kernel: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND
> Apr 20 23:14:44 1762811 kernel: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us 7 times, consider switching to WQ_UNBOUND
> Apr 20 23:14:44 1762811 kernel: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us 11 times, consider switching to WQ_UNBOUND
> Apr 20 23:14:44 1762811 kernel: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us 19 times, consider switching to WQ_UNBOUND
> Apr 20 23:14:44 1762811 kernel: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us 35 times, consider switching to WQ_UNBOUND
> Apr 20 23:14:44 1762811 kernel: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us 67 times, consider switching to WQ_UNBOUND
> Apr 20 23:14:44 1762811 kernel: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us 131 times, consider switching to WQ_UNBOUND
> Apr 20 23:14:44 1762811 kernel: workqueue: work_for_cpu_fn hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND
> Apr 20 23:14:44 1762811 kernel: workqueue: work_for_cpu_fn hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND
> Apr 20 23:14:44 1762811 kernel: workqueue: work_for_cpu_fn hogged CPU for >10000us 7 times, consider switching to WQ_UNBOUND
> Apr 20 23:14:45 1762811 kernel: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us 259 times, consider switching to WQ_UNBOUND
> Apr 20 23:15:15 1762811 kernel: workqueue: output_poll_execute hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND
> Apr 20 23:15:25 1762811 kernel: workqueue: output_poll_execute hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND
> Apr 20 23:15:46 1762811 kernel: workqueue: output_poll_execute hogged CPU for >10000us 7 times, consider switching to WQ_UNBOUND
> Apr 20 23:16:27 1762811 kernel: workqueue: output_poll_execute hogged CPU for >10000us 11 times, consider switching to WQ_UNBOUND
> Apr 20 23:16:45 1762811 kernel: workqueue: vmstat_update hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND
> Apr 20 23:16:45 1762811 kernel: workqueue: vmstat_update hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND
> Apr 20 23:16:45 1762811 kernel: workqueue: vmstat_update hogged CPU for >10000us 7 times, consider switching to WQ_UNBOUND
> Apr 20 23:16:45 1762811 kernel: workqueue: vmstat_update hogged CPU for >10000us 11 times, consider switching to WQ_UNBOUND
> Apr 20 23:16:45 1762811 kernel: workqueue: vmstat_update hogged CPU for >10000us 19 times, consider switching to WQ_UNBOUND
> Apr 20 23:17:49 1762811 kernel: workqueue: output_poll_execute hogged CPU for >10000us 19 times, consider switching to WQ_UNBOUND
> Apr 20 23:20:33 1762811 kernel: workqueue: output_poll_execute hogged CPU for >10000us 35 times, consider switching to WQ_UNBOUND
> Apr 20 23:26:00 1762811 kernel: workqueue: output_poll_execute hogged CPU for >10000us 67 times, consider switching to WQ_UNBOUND
> Apr 20 23:36:56 1762811 kernel: workqueue: output_poll_execute hogged CPU for >10000us 131 times, consider switching to WQ_UNBOUND
> Apr 20 23:58:46 1762811 kernel: workqueue: output_poll_execute hogged CPU for >10000us 259 times, consider switching to WQ_UNBOUND
> Apr 21 00:34:27 1762811 kernel: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us 515 times, consider switching to WQ_UNBOUND
> Apr 21 00:42:28 1762811 kernel: workqueue: output_poll_execute hogged CPU for >10000us 515 times, consider switching to WQ_UNBOUND
> Apr 21 02:09:51 1762811 kernel: workqueue: output_poll_execute hogged CPU for >10000us 1027 times, consider switching to WQ_UNBOUND
> Apr 21 03:27:40 1762811 kernel: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us 1027 times, consider switching to WQ_UNBOUND
> Apr 21 05:04:37 1762811 kernel: workqueue: output_poll_execute hogged CPU for >10000us 2051 times, consider switching to WQ_UNBOUND
> Apr 21 08:09:39 1762811 kernel: workqueue: vmstat_update hogged CPU for >10000us 35 times, consider switching to WQ_UNBOUND
> Apr 21 08:10:07 1762811 kernel: workqueue: vmstat_update hogged CPU for >10000us 67 times, consider switching to WQ_UNBOUND
> Apr 21 08:10:10 1762811 kernel: workqueue: vmstat_update hogged CPU for >10000us 131 times, consider switching to WQ_UNBOUND
> Apr 21 08:10:21 1762811 kernel: workqueue: vmstat_update hogged CPU for >10000us 259 times, consider switching to WQ_UNBOUND
> Apr 21 09:14:18 1762811 kernel: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us 2051 times, consider switching to WQ_UNBOUND
> Apr 21 10:54:08 1762811 kernel: workqueue: output_poll_execute hogged CPU for >10000us 4099 times, consider switching to WQ_UNBOUND
> Apr 21 21:11:47 1762811 kernel: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us 4099 times, consider switching to WQ_UNBOUND
> Apr 21 22:33:11 1762811 kernel: workqueue: output_poll_execute hogged CPU for >10000us 8195 times, consider switching to WQ_UNBOUND
> Apr 22 20:31:04 1762811 kernel: workqueue: drm_fb_helper_damage_work hogged CPU for >10000us 8195 times, consider switching to WQ_UNBOUND
> Apr 22 21:51:17 1762811 kernel: workqueue: output_poll_execute hogged CPU for >10000us 16387 times, consider switching to WQ_UNBOUND
These all appear to be workqueue warnings about functions that are
hogging CPU. If I look carefully, it looks like they are all possibly
related to the same mgag200 driver. At the very least
output_poll_execute is certainly related to the mgag200 stall.
I do noot understand exactly what is causing the driver to get stuck,
its something in the i2c routine for reading the EDID block.
I also see this being printed:
EDID block 0 (tag 0x00) checksum is invalid, remainder is 125
It appears to print quite consistently every few seconds. I guess this
might be possibly related to a bad EDID block on the mgag200 device?
What does this even mean?
I am not sure how I'd go about verifying this, or root causing what is
going wrong.
It looks like we print the message as part of _drm_do_get_edid(), and
this definitely is called as part of the mgag200 routines:
> - 33.33% 33.33% kworker/64:1-ev [kernel.kallsyms] [k] _drm_do_get_edid
> ret_from_fork_asm
> ret_from_fork
> kthread
> worker_thread
> process_one_work
> output_poll_execute
> drm_client_dev_hotplug
> drm_fbdev_shmem_client_hotplug
> drm_fb_helper_hotplug_event
> drm_client_modeset_probe
> drm_helper_probe_single_connector_modes
> mgag200_vga_bmc_connector_helper_get_modes
> drm_connector_helper_get_modes
> drm_edid_read
> drm_edid_read_custom
> _drm_do_get_edid
This makes me think that we're reading a bad EDID. I enabled drm.debug
setting to get more data:
> Apr 22 23:47:11 1762811 kernel: EDID block 0 (tag 0x00) checksum is invalid, remainder is 125
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:connector_bad_edid] [CONNECTOR:36:VGA-1] EDID is invalid:
> Apr 22 23:47:11 1762811 kernel: [00] BAD 00 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff
> Apr 22 23:47:11 1762811 kernel: [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> Apr 22 23:47:11 1762811 kernel: [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> Apr 22 23:47:11 1762811 kernel: [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> Apr 22 23:47:11 1762811 kernel: [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> Apr 22 23:47:11 1762811 kernel: [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> Apr 22 23:47:11 1762811 kernel: [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> Apr 22 23:47:11 1762811 kernel: [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1280x720": 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1280x768": 60 68250 1280 1328 1360 1440 768 771 778 790 0x40 0x9 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1280x768": 60 79500 1280 1344 1472 1664 768 771 778 798 0x40 0x6 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1280x800": 60 71000 1280 1328 1360 1440 800 803 809 823 0x40 0x9 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1280x800": 60 83500 1280 1352 1480 1680 800 803 809 831 0x40 0x6 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1280x960": 60 108000 1280 1376 1488 1800 960 961 964 1000 0x40 0x5 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1280x1024": 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x40 0x5 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1360x768": 60 85500 1360 1424 1536 1792 768 771 777 795 0x40 0x5 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1366x768": 60 85500 1366 1436 1579 1792 768 771 774 798 0x40 0x5 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1366x768": 60 72000 1366 1380 1436 1500 768 769 772 800 0x40 0x5 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1400x1050": 60 101000 1400 1448 1480 1560 1050 1053 1057 1080 0x40 0x9 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1400x1050": 60 121750 1400 1488 1632 1864 1050 1053 1057 1089 0x40 0x6 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1440x900": 60 88750 1440 1488 1520 1600 900 903 909 926 0x40 0x9 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1440x900": 60 106500 1440 1520 1672 1904 900 903 909 934 0x40 0x6 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1600x900": 60 108000 1600 1624 1704 1800 900 901 904 1000 0x40 0x5 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1600x1200": 60 162000 1600 1664 1856 2160 1200 1201 1204 1250 0x40 0x5 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1680x1050": 60 119000 1680 1728 1760 1840 1050 1053 1059 1080 0x40 0x9 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1680x1050": 60 146250 1680 1784 1960 2240 1050 1053 1059 1089 0x40 0x6 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1792x1344": 60 204750 1792 1920 2120 2448 1344 1345 1348 1394 0x40 0x6 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1856x1392": 60 218250 1856 1952 2176 2528 1392 1393 1396 1439 0x40 0x6 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0xa (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1920x1200": 60 154000 1920 1968 2000 2080 1200 1203 1209 1235 0x40 0x9 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1920x1200": 60 193250 1920 2056 2256 2592 1200 1203 1209 1245 0x40 0x6 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "1920x1440": 60 234000 1920 2048 2256 2600 1440 1441 1444 1500 0x40 0x6 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_mode_prune_invalid] Rejected mode: "2048x1152": 60 162000 2048 2074 2154 2250 1152 1153 1156 1200 0x40 0x5 (VIRTUAL_X)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:36:VGA-1] probed modes:
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_helper_probe_single_connector_modes] Probed mode: "1024x768": 60 65000 1024 1048 1184 1344 768 771 777 806 0x48 0xa
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_helper_probe_single_connector_modes] Probed mode: "800x600": 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_helper_probe_single_connector_modes] Probed mode: "800x600": 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_helper_probe_single_connector_modes] Probed mode: "848x480": 60 33750 848 864 976 1088 480 486 494 517 0x40 0x5
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_helper_probe_single_connector_modes] Probed mode: "640x480": 60 25175 640 656 752 800 480 490 492 525 0x40 0xa
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_client_modeset_probe] [CONNECTOR:36:VGA-1] enabled? yes
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_client_modeset_probe] Not using firmware configuration
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_client_modeset_probe] [CONNECTOR:36:VGA-1] looking for cmdline mode
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_client_modeset_probe] [CONNECTOR:36:VGA-1] looking for preferred mode, tile 0
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_client_modeset_probe] [CONNECTOR:36:VGA-1] Found mode 1024x768
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_client_modeset_probe] picking CRTCs for 1024x768 config
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_client_modeset_probe] [CRTC:34:crtc-0] desired mode 1024x768 set (0,0)
> Apr 22 23:47:11 1762811 kernel: mgag200 0000:b5:00.0: [drm:drm_client_dev_hotplug] fbdev: ret=0
Does anyone have any idea whats going wrong here? A google search seems
to imply this is reading the EDID data from the VGA cable...
I'm also curious if its possible to stop polling for so long with udelay
in the i2c logic somehow? I am not very familiar with i2c, but it is
frustrating that this driver is causing yet another stall that is
impacting timing sensitive data. Even if in this case its due to a
faulty cable.. it is frustrating that such result causes the PTP
failures. Would switching to WQ_UNBOUND be helpful here at all?
Thanks,
Jake
next reply other threads:[~2026-04-22 23:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-22 23:55 Jacob Keller [this message]
2026-04-23 0:05 ` further issues with MGA G200 graphics chipset David Airlie
2026-04-23 21:39 ` Jacob Keller
2026-04-23 7:44 ` Thomas Zimmermann
2026-04-23 16:35 ` Jacob Keller
2026-04-23 19:22 ` Jocelyn Falempe
2026-04-23 19:42 ` Jacob Keller
2026-04-23 21:02 ` David Airlie
2026-04-23 21:18 ` Jacob Keller
2026-04-24 6:16 ` Thomas Zimmermann
2026-04-24 6:20 ` Thomas Zimmermann
2026-04-24 7:36 ` Jocelyn Falempe
2026-04-24 7:47 ` Thomas Zimmermann
2026-04-24 23:29 ` Jacob Keller
2026-04-27 12:14 ` Thomas Zimmermann
2026-04-27 22:53 ` Jacob Keller
2026-04-27 23:32 ` Jacob Keller
2026-04-28 19:12 ` stuart hayes
2026-04-28 21:07 ` Jacob Keller
2026-04-29 6:40 ` Thomas Zimmermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=76aba88d-ec23-4b3c-ad91-83face0c3e94@intel.com \
--to=jacob.e.keller@intel.com \
--cc=airlied@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jfalempe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pvaanane@redhat.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox