Re: further issues with MGA G200 graphics chipset

[Jacob Keller <jacob.e.keller@intel.com>]

On 4/28/2026 12:12 PM, stuart hayes wrote:
> On 4/27/2026 7:14 AM, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 25.04.26 um 01:29 schrieb Jacob Keller:
>> [...]
>>>>
>>>> So I suggest to pick Manufacturer, Product, Version as key. I'd be
>>>> surprised if we find more than a hand full of systems with the
>>>> issue. If
>>>> we see a trend or common pattern, we can generalize later on.
>>>>
>>> I think this is the best solution. Keep it focused for now. I believe
>>> Intel has two major platforms that we care about with respect to this
>>> issue. I'll see if I can dig up the data. The systems install the MGA
>>> G200 for BMC use but don't seem to expose the VGA connection.
>>>
>>> For the specific system I have that was faulty, we have the following:
>>>
>>> $ for t in system-manufacturer system-product-name system-version ; \
>>>      do dmidecode -s ${t}; \
>>> done
>>> Dell Inc.
>>> PowerEdge XR8720t
>>> Not Specified
>>>
>>>
>>>
>>> I believe there was also some concern about HP systems which similarly
>>> use this chipset, but I don't have the DMI data for that one off hand.
>>> I've asked some colleagues to confirm the situation and obtain that
>>> data. I'll get back early next week if we think there are any other
>>> systems possibly affected.
>>>
>>> In the mean time, I'm happy to have our team test any patch to confirm
>>> that it behaves as expected and resolves the service interruptions.
>>
>> For now, I've modified the two places that have BMC support in the
>> driver. Could you please also tell me your system's exact Matrox
>> chipset or its PCI id?
>>
>> The patch is attached for your testing. It would work against drm-tip
>> or v7.1-rc1.
>>
>> I've also found the page at [1], which claims that there's a Mini-DP
>> port at the front. If so, I'd assume that there's also an extra
>> encoder chip to replace the VGA. If we ever get specs for that, we
>> could implement real support in the driver.
>>
>> In the meantime, the current fix should work. In the worst case, that
>> Mini-DP port would give a lower default resolution.
>>
>> [1] https://www.dell.com/en-us/shop/ipovw/poweredge-xr8720t?
>> hve=shop+now#techspecs_section
>>
>> Best regards
>> Thomas
>>
>>
> 
> So this patch disables DDC polling if the dmi_check_system() matches. If
> this was to happen on systems that _do_ have a physical VGA connector,
> will that port still be active, just with a resolution that may not be
> compatible with the monitor that's plugged in?
> 

That is my understanding, yes. At least as far as I can tell none of the
Dell PowerEdge systems with this chipset have a true VGA port, but it is
still unconfirmed if the mini DisplayPort is connected to the MGA G200
through some sort of encoder, and how it interacts with the polling
disabled.

What I can confirm so far is that the mini Display Port output does seem
to work despite the MGA G200 driver continuously complaining about
bad/faulty EDID checksums. I haven't had time again on the system to
check the patch or confirm what happens with mgag200 polling disabled yet.

> I don't see anyone say that the DDC polling doesn't cause too much
> latency for real time kernels on other systems that do have a VGA
> connector... did I miss that, or is there a chance that a lot of other
> systems that use this driver might also have issues with a real time
> kernel?
> 

There were 2 problems so far identified:

1) the DDC polling was causing issues due to spinning where it could
sleep. I fixed that a while ago with 0e0c8f4d16de ("drm/mgag200: fix
mgag200_bmc_stop_scanout()"). This was causing 300 millisecond delays
that impacted PTP functionality. This was affecting both RT and non-RT
systems (though both setups are timing sensitive only one was actually
using PREEMPT_RT). This issue, I believe, widely affects all systems
which use the MGA G200. It has been fixed.

2) the issue I reported here. This issue appears to be possibly due to
fault in the hadware, and does not happen on *every* Dell PowerEdge we
have access to.. but it seems that the driver fails to read data over
DDC when reading the EDID data for the connector. This results in it
continuously retrying. Because i2c bit algo uses udelays, this results
in enough spinning that it impacts my PTP setup.


I do not know how wide the impacts from (2) are. I also do not know if
the issue causes problems on systems that have a VGA port and which also
have the VGA port plugged in. Given my experience, it seems entirely
plausible. Here's a more detailed summary of the issue I saw:


On regular (not PREEMPT_RT) kernel, the udelay on a CPU appears to block
the interrupts from being fired on the CPU that is spinning. The polling
doesn't use WORKQEUEUE_UNBOUND, so it schedules on the specific CPU that
was executing the scheduling function. If this happens on the same CPU
as the one that is assigned the IRQ for the ice driver, it won't fire.
Since the polling thread ends up doing udelay for potentially a long
time, it results in delaying ~20-30 milliseconds which is enough to
impact the PTP functionality.

I suspect this also causes issues with PREEMPT_RT but they might be
different issues, due to the nature of PREEMPT_RT changing a lot of the
way various critical sections work.

I am fairly certain that other timing sensitive applications will have
issues caused by this issue. It is plausible that such issues are below
the radar for many deployments and its not ultimately causing a "real"
impact for everyone.. but its definitely causing problems and hiccups
for Intel as well as some of our partners and customers. The actual
failure symptom we get is somewhat inconsistent.

Even though it fails to read the EDID every second or 2, timestamps are
only impacted every few minutes. But that missed timestamp is considered
catastrophic failure for us. It results in ptp4l going to fault and
losing synchronization for several seconds. It also means such setups do
not pass various industry tests.

We have been recently recommending that users remove the mgag200 driver.
However this is a poor workaround as it results in inability to access
the video over BMC, which some customers rely on. I also plan to confirm
whether the mini DisplayPort is also affected by the driver removal. If
it is, then removal of the driver could also result in the output being
stopped. Some of our customers rely on the BMC to connect to the system,
and I suspect it is useful to have local video access when debugging if
something goes wrong with your remote access methods.

Thus, I am trying to find another solution that resolves the issues
we're having without needing to completely remove the driver.

Thanks,
Jake

> 
>>
>>
>>>
>>> Appreciate all the feedback on this thread.
>>>
>>> Thanks,
>>> Jake
>>
>