Ticket #12377 (closed defect: fixed)

Opened 22 months ago

Last modified 20 months ago

XO-4 B1 timeout entering DCON mode

Reported by: Quozl Owned by: Quozl
Priority: low Milestone: 4-firmware
Component: ofw - open firmware Version: Development firmware
Keywords: Cc:
Action Needed: no action Verified: no
Deployments affected: Blocked By:


A long duration DCON freeze and unfreeze test was set up, consisting of:

dev /display
: hdd-led-off  led-storage-gpio# gpio-clr  ;
: hdd-led-on  led-storage-gpio# gpio-set  ;
: yy  hdd-led-on dcon-freeze hdd-led-off dcon-unfreeze  ;
: xx  begin yy key? until key drop  ;
gvsr xx gvsb xx

On XO-4 B1 SKU292 (4b18) with Q7B08.

About 3900 seconds into the test, a scrolling error began:

Timeout entering DCON mode

Interrupting the test, diagnosis showed:

  • get-msecs returned 3baf52,
  • dcon-freeze was generating the error,
  • dcon-unfreeze was not generating any error,
  • has-dcon-ram? returned true,
  • brightness keyboard keys continued to work properly,
  • mode@ returned 69 (pass-through disable, backlight enable, color swizzling enable, color anti-aliasing enable),
  • select /dcon dcon-unload or dcon-load had no effect on screen image, it continued to be live,
  • the alternate function register for GPIO 142 was correct (1), and the GPIO direction was correct (output), and gpio-pin@ 1 and tracked dcon-unload (1) and dcon-load (0),
  • a soft reset of the DCON memory controller was ineffective, (1 42 dcon! 1 ms 0 42 dcon! ),
  • a system power cycle cleared the problem.

The problem has not reproduced on two other units (SKU293, SKU294).

Change History

Changed 22 months ago by Quozl

  • next_action changed from reproduce to diagnose

Reproducible on all three units here when I returned from lunch.

Changed 21 months ago by Quozl

"don't believe this is a new problem --- when this happens in Linux, the DCON is power cycled" -- John.

Changed 21 months ago by Quozl

  • tested DCON power cycle, dcon-suspend dcon-resume did not clear problem, dcon-suspend d# 3 ms dcon-resume did clear problem.
  • tested disabling the default pull-ups on DCONSTAT and DCONIRQ#, no effect.
  • compared DCON register values between working and non-working states, no difference.
  • reviewed kernel driver, could not find code that would power cycle DCON for this problem,
  • did find a comment that "the DCON seems to get confused if we change DCONLOAD too frequently", which we are doing half the time in Open Firmware, but adding a 25 ms delay between each change does not prevent problem.

An additional observation about the symptom: the static screen shimmers for about ten seconds after the test-dcon-freeze-glitch is stopped by key press.

Changed 20 months ago by Quozl

  • next_action changed from diagnose to add to build

Fixed in svn 3543, by power cycling the DCON whenever the timeout occurs. Tested over 40k cycles.

Changed 20 months ago by Quozl

  • status changed from new to closed
  • next_action changed from add to build to no action
  • resolution set to fixed

Is in Q7B16.

Note: See TracTickets for help on using tickets.