[haiku] Re: AW: Re: white screen on boot up

  • From: Justin Stressman <jstressman@xxxxxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Wed, 8 Sep 2010 21:27:10 -0400

On Wed, Sep 8, 2010 at 8:00 PM, Stephan Assmus <superstippi@xxxxxx> wrote:

>  So the problem exists somewhere between revision r37184 and r38581. The
>> screen starts with "normal" white and gets brighter and brighter. The hard
>> disk is working all the time so it looks like Haiku is booting.
>>
>
>
> So there are like 1400 revision inbetween. I am too lazy to compute how
> many revisions you'd have to test using binary searching, but you don't have
> to test all 1400. Hint, hint. ;-)
>
> Disclaimer: I'm very math challenged. ;) But if I'm correct, it would take
something like testing 10 nightlies at most to narrow it down.

Just pick a revision in the middle if those two end points (something like
r37884. I'm making these numbers up, but you get the idea.).

Is the problem still there? If it is, then that means it was introduced
earlier. Pick a revision half way between that one at r37184 (around r37534
for instance) and try again.

If it isn't, then that means it was introduced later. Pick one around r38234
(halfway between r37884 and r38581) and try again.

Each time you cut the field in half and see if the problem is there or not.
After maybe 10 iterations of this at most, you should have it narrowed down
to the revision that introduced the problem, or at least the relevant
nightly build. At that point you or the developers could look through the
commits between those 2 revisions and see which ones could cause the problem
you're seeing.

(This probably won't look quite right if you're not using a fixed width font
to display it.)

0 working revision area
? unknown possibly broken revision area
# broken revisions

works...........................broken
????????????????????????????????

you choose the middle, and since it works, you know it broke later, so you
choose the halfway point on the later side.
0000000000000000????????????????

this time it's working again still... so again we choose the halfway point
later on.
----------------00000000????????

This time it's broken, so we know it happened earlier, so we choose a
halfway earlier revision.
------------------------????####

broken again... so we scoot earlier
------------------------??##----

this one works, so we know it happened this revision and the broken revision
we tested in the last iteration.
------------------------0?------

This way it only takes a small number of tests to narrow it down from a
large number of nightly builds to just the two between which it broke.

(Remember, you don't have to narrow it down from 1,400 to begin with, just
the nightly build revisions. One you know which nightly it broke on, that's
enough to narrow it down to the relevant prior day's worth of commits to
look at for the guilty culprit.)

Hopefully I explained it well enough. :)

Other related posts: