Daniel Drake <[EMAIL PROTECTED]> wrote:
> As far as we can see, this patch was never included in any OLPC builds.
> However, we do ship some other delay improvements such as
> http://dev.laptop.org/git?p=olpc-2.6;a=commitdiff;h=4ef53002
That patch is a bit of a sledgehammer approach; it really should not be
necessary to do things that way.
> Any thoughts on where we go from here?
I'll try to look into it tomorrow. Things may be slow; whenever I get
back into OLPC stuff after a long lapse it always seems to take me a day
to get back to where I can build new kernels and successfully install
them on a laptop.
Meanwhile:
> I added a loop counter and made it print out a message when it reaches
> the 500th iteration. It hit the condition rather quickly, and in the
> first case: addr=0x42 command=0x46 value=0x58
How quickly? Given the schedule_timeout(1) call, it should take a good
five seconds to iterate five hundred times at HZ=100. Might you
(generic OLPC "you") have bumped HZ at some point? If you have a
moment, could you try restoring the upstream code, but changing the
schedule_timeout() line to:
schedule_timeout(10);
My current hypothesis is that something is making the timeout happen too
quickly; if you try to query the Cafe chip too soon after starting an
SMBUS transfer, it goes off into a sulk and does weird things. Assuming
that it's not interrupting (and it shouldn't be given that it has no
status to report), lengthening the timeout should tell whether this idea
has any basis in reality or not.
Thanks,
jon
_______________________________________________
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
