Bug 22100 - xf86-video-geode crashes on start since 2.11.x when DDC/UART mux is in UART mode
Summary: xf86-video-geode crashes on start since 2.11.x when DDC/UART mux is in UART mode
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/geode (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-04 17:29 UTC by Mart Raudsepp
Modified: 2016-02-02 03:36 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Possible fix (2.25 KB, patch)
2015-12-02 01:42 UTC, Connor Behan
no flags Details | Splinter Review
Improved fix (2.85 KB, patch)
2016-02-02 03:36 UTC, Connor Behan
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Mart Raudsepp 2009-06-04 17:29:20 UTC
Since the RANDR1.2 port in xf86-video-geode-2.11 the driver crashes on X.org startup immediately if the firmware has set up the DDC/UART muxed GPIO to serial port (UART) mode.

Before there was code made to detect the GPIO mode and not do any DDC queries if it is in serial port mode. But while that checking still exists and the fact that it is in UART mode gets reported in Xorg.0.log, DDC calls are still made through RANDR impementation vfunc regardless of that, and Xorg crashes on the results that gets to in UART mode.

This bug is the primary reason 2.11 is not packaged in Gentoo Linux yet, as it breaks things for my own geode platform development :(
Comment 1 Mart Raudsepp 2010-04-19 19:34:49 UTC
A workaround is Option "NoDDC" in xorg.conf. Probably just need to add some checks in the right place of the randr1.2 interface implementation to not call into EDID xserver code when we have figured out we are in serial mode.
(and 2.11 series has been packaged in gentoo for quite a long while now)
Comment 2 Martin-Éric Racine 2010-08-23 09:24:57 UTC
Does this bug still apply to Geode 2.11.9 or not?
Comment 3 Martin-Éric Racine 2010-10-27 00:53:08 UTC
AMD might be willing to fix this, since this involves a standard Geode feature, but additional details might need to be provided to this bug report.
Comment 4 Martin-Éric Racine 2010-11-05 13:18:25 UTC
One solution could be to make our driver bit-bang the GPIO into DDC mode, early in the driver startup pahse, to ensure that DDC probing will always work.
Comment 5 Priit Laes (irc: plaes) 2011-01-03 23:14:59 UTC
The crash only happens on LX hardware.
Comment 6 Martin-Éric Racine 2011-01-10 03:53:30 UTC
LX hardware happens to be the majority of what's left of the Geode market.
Comment 7 Zoltán Böszörményi 2015-11-24 13:15:18 UTC
I have two still widely used US-made POS machines with this Geode LX chip.
At least one of them actually makes use of the multiplexed DDC/UART2 gpio line for the serial connected touchscreen. If/when the KMS driver gets included in the kernel, can we have a way to use both DDC control and UART2? E.g. switching to DDC only momentarily while initializing the Geode video and allow the UART2 most of the time?
Comment 8 Connor Behan 2015-12-02 01:42:49 UTC
Created attachment 120261 [details] [review]
Possible fix

A bit lower brow than the proposal to always get DDC working.
Comment 9 Martin-Éric Racine 2016-02-01 15:54:12 UTC
Thanks for the patch.

This does a fair job of avoiding an explicit crash whenever DDC is unavailable.

When that happens, restricting available modes to those that AMD considers safe i.e. Panel-friendly modes, is indeed a promising strategy.

However, that strategy doesn't guarantee that the selected mode is something that the connected VGA monitor can handle. It's a shot in the dark and the mode we try, 1920x1440, is a large enough size (and an uncommon enough resolution) that we cannot consider that shot in the dark to be a safe one.

Thinking out loud, 800x600, 1024x768 or 1280x1024 would probably be safer modes to attempt whenever DDC is unavailable, pretty much in that order.
Comment 10 Connor Behan 2016-02-02 03:36:40 UTC
Created attachment 121450 [details] [review]
Improved fix

You're right. The panel resolution would usually be too big for an external display. This new patch picks the largest mode mentioned in xorg.conf if anything is there. Otherwise it uses those three modes with a preference for 800x600.


bug/show.html.tmpl processed on Mar 29, 2017 at 22:51:58.
(provided by the Example extension).