[Openchrome-users] [openChrome] #288: openchrome interferes with PCI-Express

[OpenChrome Trac]

#288: openchrome interferes with PCI-Express
--------------------+-------------------------------------------------------
 Reporter:  ljacob  |        Owner:  jnettlet      
     Type:  defect  |       Status:  closed        
 Priority:  major   |    Component:  initialization
  Version:  trunk   |   Resolution:  fixed         
 Keywords:          |     Blocking:  261           
Blockedby:          |  
--------------------+-------------------------------------------------------

Comment(by stuge):

 Summary : The bug is fixed with r758. Thanks for applying the patch. Could
 someone please bump all those distribution bugs and mention that this is
 now fixed?

 Replying to [comment:41 Zajec]:
 > These bits are not reserved, so why this cause corruption?

 Before r758 the driver would always set the state of both LVDS drivers in
 the chipset to on or off when asked to set the state of the panel,
 regardless of which LVDS driver, if any, was actually being used in the
 system.

 > Applied patch workarounds it, but problem is still not
 explained/understood.

 I tried to explain the problem in [comment:37] but I was maybe not
 completely clear.

 Please look at the log file
 http://www.openchrome.org/trac/attachment/ticket/288/lvds.debugging.Xorg.log
 which contains debug output from an unmodified driver before r758.

 The first time ViaLVDSDFPPower() is called after X has been started, the
 0x2a sequencer register contains 3. (The first ''before'' value.) When
 xset is run to disable the display, 0 is written to the register. No
 problem so far. When space is pressed and the display should be enabled
 again, the function writes 0xF instead of 3 which was there before. This
 is the problem. This means that the LVDS channel 2 driver is suddenly
 enabled, although it was always disabled before. In the HP 2133 this
 causes a problem with PCI-Express, and other systems with the same chipset
 could be affected in the same way. Digital video out and PCIe are closely
 connected inside this chipset, so the phenomenon is not too surprising,
 although the two may seem unrelated at first.


 Replying to [comment:43 Zajec]:
 > I belive current solution is something we should really use.
 > I'm just afraid some day we will hit this bug again on some device with
 two channels.

 My patch which was applied in r758 changes ViaLVDSDFPPower() so that it
 will never enable an LVDS channel which was not enabled on the last switch
 by X from text mode VT to graphics mode. If both LVDS channels were
 enabled at that time, then both channels will be enabled after DPMS
 off/on. If only one channel was enabled (regardless of if it was ch. 1 or
 ch. 2), then only that channel will be enabled. If no channel was enabled
 (weird case), then no channel will be enabled. This is a generic fix.

 It is still possible to mess things up by manually changing the registers
 in text mode, switching to X graphics mode and then doing DPMS off/on. If
 anyone does that, I think they will also understand the risks, and this
 issue. It could be argued that it is a feature for the driver to adapt to
 the new register value which was manually set while in text mode, but my
 point is that it will not happen often, if at all, and if it does happen,
 the person tweaking registers needs to know what they are doing anyway.

-- 
Ticket URL: <http://www.openchrome.org/trac/ticket/288#comment:44>
openChrome <http://www.openchrome.org/>
The openChrome project