#9100 NORM 10.1.2: 2.6.27+ early boot crashes on XO1
Zarro Boogs per Child
bugtracker at laptop.org
Mon Jul 26 21:12:47 EDT 2010
#9100: 2.6.27+ early boot crashes on XO1
--------------------------------+-------------------------------------------
Reporter: dsd | Owner: dsaxena
Type: defect | Status: new
Priority: normal | Milestone: 10.1.2
Component: kernel | Version: Development build as of this date
Resolution: | Keywords:
Next_action: diagnose | Verified: 0
Deployment_affected: | Blockedby:
Blocking: |
--------------------------------+-------------------------------------------
Comment(by hal.murray):
I think there are two parts to this discussion.
What should we do for this particular bug?
What can we do to get ready for similar bugs in the future?
How much code is there before normal screen output works?
> * the LEDs ... from memory there's a GPIO to toggle ... and
> with a series of kernels over several days a kernel developer
> may find the point of failure. An ugly prospect.
Something like binary search assumes we have a reasonable test case. I'm
not sure that's true. I've only hit it twice, and that was probably by
accident/luck rather than because I have a good recipe.
How many LEDs are there that are easy to control from the CPU and/or EC?
Can we learn enough with simple binary encoding? [It died between step X
and step X+1.]
You can send a lot of info through a single LED by encoding a number as
blink patterns. The key idea is that you aren't in a hurry so you can
transmit slowly and retransmit many times so the observer can double
check. Consider something like:
Blink, Blink, Blink, pause, Blink, Blink, long pause, repeat.
I think that approach needs something like an EC to do the work.
--
Ticket URL: <http://dev.laptop.org/ticket/9100#comment:34>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system
More information about the Bugs
mailing list