linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* RE: gdbserver ppc8xx
@ 2002-03-01 10:07 Goddeeris Frederic
  2002-03-01 10:49 ` Christian Pellegrin
  2002-03-01 17:01 ` Owen Green
  0 siblings, 2 replies; 8+ messages in thread
From: Goddeeris Frederic @ 2002-03-01 10:07 UTC (permalink / raw)
  To: 'Owen Green ', 'Christian Pellegrin '
  Cc: 'linuxppc-embedded@lists.linuxppc.org '


Did you try using strace? This can give you info about why gdbserver quits.

I also had a problem with gdbserver and this is the way I solved it...

Fred

-----Original Message-----
From: Owen Green
To: Christian Pellegrin
Cc: linuxppc-embedded@lists.linuxppc.org
Sent: 2/28/02 2:50 PM
Subject: Re: gdbserver ppc8xx


--- Christian Pellegrin <chri@infis.univ.trieste.it>
wrote:
> On Wed, 27 Feb 2002, Owen Green wrote:
>
> > edition but I got something like:
> > #gdbserver :7777 /bin/test
> > Process /bin/test created; pid = 48
> > getprotobyname:Sucess.
> > Exiting
> > #
> just copy /etc/protocols from whatever distro you
> like. Bye!
>

This did not work, I got the getprotobyname: Sucess,
what means my /etc/protocols have the entry for tcp.
Thanks anyway.


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

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: Linux 2.4.17 bug, mmap of /dev/mem
@ 2002-02-27 21:06 Dan Malek
  2002-02-27 21:47 ` gdbserver ppc8xx Owen Green
  0 siblings, 1 reply; 8+ messages in thread
From: Dan Malek @ 2002-02-27 21:06 UTC (permalink / raw)
  To: David Ashley; +Cc: linuxppc-embedded


David Ashley wrote:

> I've traced the problem down to arch/ppc/mm/hashtable.S. When
> there is a page fault, the function hash_page gets called.

In the case of a 603 core, hash_page is called for DSI (Data Access)
faults.  However, if the feature indicates there is no HPTE, the
hash_page function is patched to simply return.  You can't look at
the code in hashtable.S and know how it is going to work for a particular
implementation because it is patched at initialization to change
it's behavior.

> .....This does
> some hashing and writes the hash values into a table located at
> 0xc0180000.

When your kernel boots, does it print a message to indicate it has allocated
a hash table?

> In arch/ppc/mm/ppc_mmu.c the function MMU_init_hw is called, but
> since the 8260 doesn't have the CPU_FTR_HPTE_TABLE feature, the
> hash table is never allocated and the hash_page_patch_* never get updated.


Oh, I just looked at a variety of different versions back to 2.4.11, and it
is patched just as I described above.


	-- Dan


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2002-03-01 17:14 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-03-01 10:07 gdbserver ppc8xx Goddeeris Frederic
2002-03-01 10:49 ` Christian Pellegrin
2002-03-01 17:01 ` Owen Green
2002-03-01 17:14   ` Mark Hatle
  -- strict thread matches above, loose matches on Subject: below --
2002-02-27 21:06 Linux 2.4.17 bug, mmap of /dev/mem Dan Malek
2002-02-27 21:47 ` gdbserver ppc8xx Owen Green
2002-02-27 22:03   ` Wolfgang Denk
2002-02-28  8:01   ` Christian Pellegrin
2002-02-28 13:50     ` Owen Green

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).