ffreep support on Geode LX (XO-1)

[pgf at laptop.org]

daniel wrote:
 > 2009/5/7 NoiseEHC <NoiseEHC at freemail.hu>:
 > >
 > >> please file a ticket at dev.laptop.org, with details on how to
 > >> reproduce the ffreep issue using build 802.  (if it's only
 > >> reproducible with debxo (unclear from what's been written so
 > >> far), then the priority (and the fix) will likely be very
 > >> different.)
 > >>
 > >>
 > > I cannot reproduce it reliably so I do not know what should I file as a
 > > bug. What I have seen with 800 (months ago) can be seen here:
 > > http://wiki.laptop.org/go/Image:Xo_freeze_on_shutdown.png
 > > I think that it is sure that at least some parts of the 80x versions
 > > contain some code compiled with illegal instructions.
 > 
 > I'm pretty sure the shutdown "freeze" (which can be unfrozen by using
 > ctrl+alt+f1/f2 to change terminals) is totally unrelated to any
 > instruction problems. I am pretty sure I have an explanation of the
 > shutdown freeze, it's a race that occurs when 2 processes try to chvt
 > at the same time (the 2 processes being X as it terminates and moves
 > to the console, and ul-warning as it tries to move to the graphical
 > terminal). Examining chvt source code makes it pretty obvious why this
 > might happen... The switch process is actually switch-and-wait,
 > performed by 2 separate ioctls, and hence is not atomic.
 > 
 > I tried adding appropriate diagnostics once but this occurs
 > frustratingly rarely that I never got to see if my theory is correct.

i think you're exactly right -- the fact that ul-warning completes
when you manually switch screens is pretty convincing.  i'm
amazed the vt system has never grown a new api of some sort to
fix this problem.  because powerd puts up an additional shutdown
splash screen prior to the ul-warning screen, the sequencing is
perturbed, and i see it (the race) more often.

i think we should apply the bandaid of a retry to the chvt code --
i.e., add a timeout to the wait, and retry (or, at the very
least, exit) if it expires.  i actually went in to make the code
changes the other day, but i backed off when i realized the
source was in pyrex, not C.  i realized i wasn't sure i'd be able
to do the signal handling successfully (in the time i'd allotted
myself, at any rate).

paul

 > 
 > Daniel

=---------------------
 paul fox, pgf at laptop.org