Re: further issues with MGA G200 graphics chipset

[Thomas Zimmermann <tzimmermann@suse.de>]

Hi

Am 23.04.26 um 23:02 schrieb David Airlie:
[...]
>> Faulty hardware (perhaps just a cheap pull down resistor on the VGA
>> connection as Dave Airlie suggests) means that any such affected
>> platform has a polling routine that causes significant issues on any
>> timing sensitive applications.
> We could write a patch to just say if we see 10 bogus EDID polls we
> just give up and loudly say in the logs.

I don't think we should do that. The fallout might just backfire as well.

Best regards
Thomas

>
> This might break some crash-cart plugins in some data centers though,
> I don't think we have contracts in Matrox or the server vendors who
> make the hw to say how they recommend finding this info.
>
> It might be in ACPI or dmidecodes.
>
> Dave.
>
>
>> Right now, I am stuck in a situation which means that I have to fight to
>> reach every customer who uses one of these platforms and confirm they
>> either disable polling or ban the module so it won't even load.
>>
>> This is frustrating, as it is unlikely I'll reach everyone.
>>
>> I doubt that I'm the only one with users who are affected by mysterious
>> performance or timing problems related to this. While its true that not
>> *every* instance of the device is problematic (at least not now that we
>> fixed the other issue with the udelay...), but many systems using the
>> controller *are* negatively impacted even with the timing fix, as I have
>> now seen...
>>
>> Unfortunately, I also have no better idea than a DMI quirk table to
>> record known platforms that include the controller but don't have a
>> physical VGA connection exposed.
>>
>> Thus, I'm wondering what else we can do? Using WQ_UNBOUND might help
>> somewhat? I have no idea if its safe to sleep instead of spin while
>> reading the i2c connections... As far as I can tell the non-atomic
>> version has nothing that *strictly* prevents sleep.. but maybe i2c
>> access has tighter timing requirements than what usleep_range can
>> fulfill? I am not sure...
>>
>> I'd just really like to not have to worry about going to every single
>> user and asking them to unload and ban a driver for these big server
>> platforms...
>>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)