Problems with linuxppc_2_4_devel

Problems with linuxppc_2_4_devel

[Anders Blomdell]

I'm still unsuccessful with running linux on my prpmc800 card (and my 2600
card as well)

1. The 2600 does its thing up to the
      Uncompressing Linux...done.
      Now booting the kernel
    point, then it changes the console speed to some (yet) undetermined
value, how
    do I change that?

2. The prpmc800 is just quiet (and unresponsive) after
      Network Boot File load in progress... To abort hit <BREAK>

      Bytes Received =&694852, Bytes Loaded =&694852
      Bytes/Second   =&694852, Elapsed Time =1 Second(s)

      Residual-Data Located at: $07EBE4FC

Anybody that has a clue (or a working .config to share?)

Regards

Anders Blomdell


------------------------------------------------------------------------------
  Anders Blomdell
  Department of Automatic Control        Email: anders.blomdell@control.lth.
se
  Lund Institute of Technology           Phone: +46 46 222 4625
  Box 118, S-221 00 Lund, Sweden         Fax:   +46 46 138118


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problems with linuxppc_2_4_devel

[Tom Rini]

On Thu, Oct 10, 2002 at 05:22:28PM +0200, Anders Blomdell wrote:

> I'm still unsuccessful with running linux on my prpmc800 card (and my 2600
> card as well)
>
> 1. The 2600 does its thing up to the
>      Uncompressing Linux...done.
>      Now booting the kernel
>    point, then it changes the console speed to some (yet) undetermined
> value, how
>    do I change that?

What are you running it in the firmware?  It defaults to 9600 8n1,
unless you pass it another speed (console=ttyS0,38400 for example).

> 2. The prpmc800 is just quiet (and unresponsive) after
>      Network Boot File load in progress... To abort hit <BREAK>
>
>      Bytes Received =&694852, Bytes Loaded =&694852
>      Bytes/Second   =&694852, Elapsed Time =1 Second(s)
>
>      Residual-Data Located at: $07EBE4FC
>
> Anybody that has a clue (or a working .config to share?)

make prpmc800_config

And then fixup
arch/ppc/platforms/prpmc800_setup.c::prpmc800_openpic_initsenses
(iirc, '1' -> IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE.  But grab the
prpmc800 manual and update the IRQ table occordingly) and submit a
patch.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Problems with linuxppc_2_4_devel

[Kenneth Johansson]

I have some date problem BK think that we are at feb23 and that dose not look
right when running revtool. Do anyone else see this or is it my clone?


Also I get alot of "ERROR-cannot cd to linuxppc_2_4_devel" when running bk
pull


--
Kenneth Johansson
Ericsson Telecom AB               Tel: +46 8 404 71 83
Viderögatan 3                     Fax: +46 8 404 72 72
164 80 Stockholm                  kenneth.johansson@etx.ericsson.se

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problems with linuxppc_2_4_devel

[Tom Rini]

On Tue, Jan 15, 2002 at 01:21:26PM +0100, Kenneth Johansson wrote:
>
> I have some date problem BK think that we are at feb23 and that dose not look
> right when running revtool. Do anyone else see this or is it my clone?
>
>
> Also I get alot of "ERROR-cannot cd to linuxppc_2_4_devel" when running bk
> pull

What does:
$ bk parent
say (from your source tree)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problems with linuxppc_2_4_devel

[Gabriel Paubert]

On Tue, 15 Jan 2002, Tom Rini wrote:

>
> On Tue, Jan 15, 2002 at 01:21:26PM +0100, Kenneth Johansson wrote:
> >
> > I have some date problem BK think that we are at feb23 and that dose not look
> > right when running revtool. Do anyone else see this or is it my clone?

It is somebody who build a change set in the future :-), or at least with
its machine clock set well into the future end November. I noticed it and
Larry McVoy answered that he could not do anything since BK requires
increasing timestamps. You'll find it in the archives of linuxppc-dev for
November 2001.

IOW, check that your clock is not borked before committing changesets...

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problems with linuxppc_2_4_devel

[Larry McVoy]

> IOW, check that your clock is not borked before committing changesets...

Would you like me to make you a "pre-commit" trigger which catches these
problems?
--
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problems with linuxppc_2_4_devel

[Tom Rini]

On Tue, Jan 15, 2002 at 11:22:33AM -0800, Larry McVoy wrote:

> Would you like me to make you a "pre-commit" trigger which catches these
> problems?

If you've got the time, sure.  Hopefully we're all done breaking our
clocks tho. :)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problems with linuxppc_2_4_devel

[Larry McVoy]

What I was thinking was one of two approaches:

a) try and connect to a well known time server and see if the time is too
   far off at commit time.  May or may not work.
b) see if the time is "too different" from the last changeset.  Most trees
   are fairly active and if the time is too far ahead (say a month?), then
   raise a warning and ask the user to confirm this is the correct time.

Comments?

On Tue, Jan 15, 2002 at 01:57:55PM -0700, Tom Rini wrote:
> On Tue, Jan 15, 2002 at 11:22:33AM -0800, Larry McVoy wrote:
>
> > Would you like me to make you a "pre-commit" trigger which catches these
> > problems?
>
> If you've got the time, sure.  Hopefully we're all done breaking our
> clocks tho. :)
>
> --
> Tom Rini (TR1265)
> http://gate.crashing.org/~trini/

--
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problems with linuxppc_2_4_devel

[Tom Rini]

On Tue, Jan 15, 2002 at 01:02:03PM -0800, Larry McVoy wrote:

> a) try and connect to a well known time server and see if the time is too
>    far off at commit time.  May or may not work.

This would require some external program tho, wouldn't it?

> b) see if the time is "too different" from the last changeset.  Most trees
>    are fairly active and if the time is too far ahead (say a month?), then
>    raise a warning and ask the user to confirm this is the correct time.

I'd say 'b' with an override option (yes, the clock IS fine, the tree
has just been dead for awhile).

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problems with linuxppc_2_4_devel

[Gabriel Paubert]

On Tue, 15 Jan 2002, Tom Rini wrote:

> On Tue, Jan 15, 2002 at 01:02:03PM -0800, Larry McVoy wrote:
>
> > a) try and connect to a well known time server and see if the time is too
> >    far off at commit time.  May or may not work.
>
> This would require some external program tho, wouldn't it?

It's called ntpq, and I believe most people should have it installed, even
if they don't go to full ntpd synchornisation. Besides that, the NTP
protocol is very simple, especially if you don't care about round trip
time measurement: it's UDP (on port 123 AFAIR).

>
> > b) see if the time is "too different" from the last changeset.  Most trees
> >    are fairly active and if the time is too far ahead (say a month?), then
> >    raise a warning and ask the user to confirm this is the correct time.
>
> I'd say 'b' with an override option (yes, the clock IS fine, the tree
> has just been dead for awhile).

Probably the best solution indeed...

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problems with linuxppc_2_4_devel

[Tom Rini]

On Wed, Jan 16, 2002 at 12:39:58PM +0100, Gabriel Paubert wrote:
>
>
> On Tue, 15 Jan 2002, Tom Rini wrote:
>
> > On Tue, Jan 15, 2002 at 01:02:03PM -0800, Larry McVoy wrote:
> >
> > > a) try and connect to a well known time server and see if the time is too
> > >    far off at commit time.  May or may not work.
> >
> > This would require some external program tho, wouldn't it?
>
> It's called ntpq, and I believe most people should have it installed
[snip]

Should doesn't mean they will tho. :)  And the first time you assume
everyone has something, 5 people pop up screaming 'cuz they don't.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problems with linuxppc_2_4_devel

[Gabriel Paubert]

On Wed, 16 Jan 2002, Tom Rini wrote:

> On Wed, Jan 16, 2002 at 12:39:58PM +0100, Gabriel Paubert wrote:
> >
> >
> > On Tue, 15 Jan 2002, Tom Rini wrote:
> >
> > > On Tue, Jan 15, 2002 at 01:02:03PM -0800, Larry McVoy wrote:
> > >
> > > > a) try and connect to a well known time server and see if the time is too
> > > >    far off at commit time.  May or may not work.
> > >
> > > This would require some external program tho, wouldn't it?
> >
> > It's called ntpq, and I believe most people should have it installed
> [snip]
>
> Should doesn't mean they will tho. :)  And the first time you assume
> everyone has something, 5 people pop up screaming 'cuz they don't.

No, but as I said, the protocol is trivial if you want a very approximate
time (use NTP v3 since all V4 servers I know support it). The problem is
finding the closest server, not sending an UDP packet and decoding the
answer and giving up if you don't receive anything after 5 packets or so.
I'm almost certain there is database of servers somewhere, but I just
don't remember where (between 2 cesium clocks, one hydrogen maser, 2 GPS
and one radio receiver I have enough references for my use at the
telescope ;-)). I also don't know whether some people could be blocked
from using NTP, but I don't think that it is a satisfactory solution in
any case.

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problems with linuxppc_2_4_devel

[Gabriel Paubert]

On Tue, 15 Jan 2002, Larry McVoy wrote:

> What I was thinking was one of two approaches:
>
> a) try and connect to a well known time server and see if the time is too
>    far off at commit time.  May or may not work.

While there are NTP servers all around the globe (and I maintain the one
we have here at work), finding the nearest one is not always easy.
Furthermore some people may create a changeset while disconnected on a
laptop or would object the cost of an additional call just to get the
time.


> b) see if the time is "too different" from the last changeset.  Most trees
>    are fairly active and if the time is too far ahead (say a month?), then
>    raise a warning and ask the user to confirm this is the correct time.

Probably better, although I like the a) solution because it is likely to
be more exact. AFAIK the bk variables in the usr home directory only
affect the GUI Tools look and feel, it would be too much a stretch to add
a time server specification, no ?

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problems with linuxppc_2_4_devel

[Paul Mackerras]

Larry McVoy writes:

> What I was thinking was one of two approaches:
>
> a) try and connect to a well known time server and see if the time is too
>    far off at commit time.  May or may not work.

Are you talking about doing this just on ppc.bkbits.net or on
everybody's repository clone as well?  I think it would be an
excellent idea for ppc.bkbits.net to reject changesets whose time is
after the current time.  I don't think we want to make everybody's
clones do that though.

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problems with linuxppc_2_4_devel

[Gabriel Paubert]

On Tue, 15 Jan 2002, Tom Rini wrote:

> On Tue, Jan 15, 2002 at 11:22:33AM -0800, Larry McVoy wrote:
>
> > Would you like me to make you a "pre-commit" trigger which catches these
> > problems?
>
> If you've got the time, sure.  Hopefully we're all done breaking our
> clocks tho. :)

Never underestimate the capability of people to screw up, seven something
as trivial as the clock ;-)

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problems with linuxppc_2_4_devel

[Gavin Hemphill]

Couldn't the pre-trigger actually check with an ntp server at the bk end
and put up a warning if the commit times are off by "too much".

Tom Rini wrote:

> On Tue, Jan 15, 2002 at 11:22:33AM -0800, Larry McVoy wrote:
>
>
>>Would you like me to make you a "pre-commit" trigger which catches these
>>problems?
>>
>
> If you've got the time, sure.  Hopefully we're all done breaking our
> clocks tho. :)
>
> --
> Tom Rini (TR1265)
> http://gate.crashing.org/~trini/
>
>
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problems with linuxppc_2_4_devel

[Gabriel Paubert]

On Wed, 16 Jan 2002, Gavin Hemphill wrote:

>
> Couldn't the pre-trigger actually check with an ntp server at the bk end
> and put up a warning if the commit times are off by "too much".

It is simpler to have the clock of the server be phase-locked on an NTP
server. I don't know where the bk servers are located but they almost
certainly have an NTP server within 100ms RTT (round-trip time). If
paranoid, the pre-trigger script could even refuse any changeset as long
as the local clock is not phase-locked, i.e., during the first few minutes
after a reboot (however the ntpdate <time-server-host> which is performed
normally during boot scripts to initially set the clock before starting
the NTP daemon should be more than sufficient).

Besides that, this is a good idea, it should only check the timestamp on
the Changeset is not in the future (bk already ensures that timestamps
ordering in the graph of changesets). A time well in the past is
acceptable since a changeset or set of changesets can be pushed well after
being done in a private tree.

After this, a developer with a bad clock can either wait to push
(if it's only a few minutes or hours in the future) or undo and redo his
changeset(s) if his/her clock was far too much in advance.

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Problems with linuxppc_2_4_devel

[Kenneth Johansson]

Tom Rini wrote:
>
> On Tue, Jan 15, 2002 at 01:21:26PM +0100, Kenneth Johansson wrote:
> >
> > I have some date problem BK think that we are at feb23 and that dose not look
> > right when running revtool. Do anyone else see this or is it my clone?
> >
> >
> > Also I get alot of "ERROR-cannot cd to linuxppc_2_4_devel" when running bk
> > pull
>
> What does:
> $ bk parent
> say (from your source tree)
>

Sorry for the delay I catched a bug unfortunately it was deoxyribonucleic
acid based instead of ones and zeros.

$bk parent
Parent repository is http://ppc.bkserver.net/linuxppc_2_4_devel

I almost always get the error but sometimes it workes. Today it worked the
first try.



--
Kenneth Johansson
Ericsson Telecom AB               Tel: +46 8 404 71 83
Viderögatan 3                     Fax: +46 8 404 72 72
164 80 Stockholm                  kenneth.johansson@etx.ericsson.se

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/