Re: further issues with MGA G200 graphics chipset

[Thomas Zimmermann]

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)