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/
next prev 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.