linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Dan A. Dickey" <ddickey@charter.net>
To: Murray Jensen <Murray.Jensen@cmst.csiro.au>
Cc: Dan Malek <dan@netx4.com>, linuxppc-embedded@lists.linuxppc.org
Subject: Re: 8xx MMU Table Walk Base (was Re: kernel crashes at InstructionTLBMiss )
Date: Tue, 06 Jun 2000 22:02:55 -0500	[thread overview]
Message-ID: <393DBB5F.DB509DA@charter.net> (raw)
In-Reply-To: 23333.960273068@msa.cmst.csiro.au


Murray Jensen wrote:
>
> On Mon, 05 Jun 2000 16:37:55 -0400, Dan Malek <dan@netx4.com> writes:
...
> >After reading your diatribe
>
> Diatribe? Hmm.. Sorry, I didn't mean to offend you - I thought I was being
> reasonably clear, and definitely polite.
...
> >Finally, lots of bugs associated with porting to new hardware manifest
> >themselves as "problems" in any VM related function.  Since many people
> >don't understand the subtle interactions of all of these functions (as
> >evidenced by your message) you become convinced the problem is associated
> >with this complexity and fail to unravel the clues to the real cause.
>
> I don't think I deserve this sort of belittling. Treating potential
> contributors in this way can only have a negative effect on open
> source development.

Murray,
please - hang in there.  We need more people like you.
Cut Dan some slack - he appears to be a genius at programming,
but maybe is a little short on people skills.  He means no harm,
but calls them as he sees them.  And as in baseball, not everyone
always agrees with the umpire.  :)
(At least; this is the impression
I've gathered in the relatively short time I've made his acquaintance
and have been reading this list).

>
> >some silicon
> >bug not understood,
>
> I included my chip revision above. It appears to be a C1 revision chip.
>
> >or prototype hardware not working correctly.
>
> Definitely.
>
> >There are lots of products and systems in development running this software,
> >so you have to approach this generic software from the assumption that
> >it is first likely to be working.
>
> I did. I said I was intrigued as to why this problem only affected me. And
> once I make the described change, the "generic software" works for me also
> (at least an older revision works - current revisions still crash, something
> to do with the memory allocation stuff, I believe).
>
> As I said in my previous message, I suspect something else I am doing is
> triggering this bug (that much is obvious), but there are two possibilities:
> either I am doing something wrong in my local changes, or the "generic
> software" has a bug which does not show up in anyone else's implementation. I
> was wondering whether the latter was the case (I wasn't blaming anyone, I was
> excited that maybe I had discovered a long existing hidden fault in the
> software, that may explain some mysterious failure modes, that someone else
> might be getting - other developers may then post, saying "yeah, that would
> explain my problem, blah blah", and so the discussion goes on. Upon searching
> the archives, I found that a similar problem had been discussed for the 2.2.x
> kernels, so maybe the fix or fixes didn't make their way into the 2.[34].x
> kernels. I don't know, anything is possible, that's why we have these
> discussion groups).

Murray,
as far as I know - you are maybe the only one running 2.3.x on
a powerpc.  Most of the kernels that one can find lying about
are 2.2.x (13/14? Can't remember at the moment).

I, as well as others, definitely want to see 2.3.x or 2.4.0 running
on an embedded powerpc.

...

> Again, apologies for not providing enough information in my message - I made
> assumptions I shouldn't have. Obviously, on my first post I should have been
> completely anal, because no-one knows me from a bar of soap. I can then start
> to be less exacting after I have been around for a while.

Everyone enjoys sarcasm... :)  (Don't they?)

> >Where did you get the sources? What
> >patches did you apply?  What are your hardware details?  What
> >modifications did you make?
>
> See above.
>
> >As for 2.4.xx, the 8xx still doesn't work correctly.  However, I
> >discovered it failed to work after the 403 additions, so I am now
> >learning about the 403 in an effort to make everything live happily
> >together again.
>
> It was my feeling that the problems were to do with the new memory allocation
> stuff introduced a couple of months ago.
>
> >Note, this has nothing to do with M_TWB......
>
> I know. Now that we have gotten past treating me like a dill, please can you
> re-read my original message and see if I am making any sense at all? I would
> very much appreciate some insights and even constructive criticism. Cheers!
>                                                                 Murray...
>
> PS: I haven't contributed the Cogent platform changes yet, because I wasn't
> happy that I had done everything properly. This was really my first foray
> into taking part in the Linux/PPC embedded development community - I can't
> say it has been particularly successful (despite my good feelings about
> contributing a small fix a couple of days ago). I will try not to be too
> discouraged.

That's the spirit!

	-Dan	(A different one).

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

  parent reply	other threads:[~2000-06-07  3:02 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-04  4:40 kernel crashes at InstructionTLBMiss Daniel Wu
2000-06-05  2:32 ` Dan A. Dickey
2000-06-05  8:19 ` 8xx MMU Table Walk Base (was Re: kernel crashes at InstructionTLBMiss ) Murray Jensen
2000-06-05 20:37   ` Dan Malek
2000-06-06  6:31     ` Murray Jensen
2000-06-06 20:05       ` Dan Malek
2000-06-07  3:05         ` Dan A. Dickey
2000-06-07  9:17         ` Murray Jensen
2000-06-07  3:02       ` Dan A. Dickey [this message]
2000-06-06 21:37         ` Steve Tarr
2000-06-06 17:03     ` net driver receive problems Tom Roberts
2000-06-05 14:51 ` kernel crashes at InstructionTLBMiss Dan Malek
2000-06-05 15:55   ` Dan Malek
2000-06-05 16:19     ` Dan Malek
2000-06-06  3:59     ` Graham Stoney
2000-06-06  3:56   ` Daniel Wu
2000-06-06 20:18     ` Dan Malek
2000-08-10 12:05     ` too few RAM? Wojciech Kromer
2000-08-10 14:49       ` Dan Malek
2000-08-17 11:49         ` Wojciech Kromer
2000-06-30  6:17 ` Debug information for elf format Kwansuk Kim
2000-06-30  6:46   ` sungyeon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=393DBB5F.DB509DA@charter.net \
    --to=ddickey@charter.net \
    --cc=Murray.Jensen@cmst.csiro.au \
    --cc=dan@netx4.com \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).