405 -- a little console help, part 2

I've got a little more info -- /bin/sash doesn't produce any
output and just sits there, echoing charachters typed.  I'll try poking
around w/ gdb/abatron but am not sure how to find the exec'd shell.

if I spawn ash w/ init=/bin/ash:
...
Looking up port of RPC 100003/2 on 192.168.200.4
Looking up port of RPC 100005/1 on 192.168.200.4
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 56k init
executing init = /bin/ash
sh: can't access tty; job control turned off
#

--  but at least I get a prompt and it seems to work.

I'm not sure what the message "can't access tty; job control turned off"
means -- I'll have to get the source for ash and debug it.

I would have thought that spawning init=/bin/sash would have been the
easiest.

the target filesystem is pieces of mvista's hhl2.0 target
for ppc405.

Since I'm nfs mounting it, I'm going to just mount the whole
thing and see if what I need turns up;  it'd be nice to know
for those wanting to run a more spare system.

Mark
--
Mark Pilon

Minolta-QMS
P.O. Box 37
Fallon, MT.  59326-0037

1-406-853-0433

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

Mark Pilon wrote:

I've got a little more info -- /bin/sash doesn't produce any
output and just sits there, echoing charachters typed.  I'll try poking
around w/ gdb/abatron but am not sure how to find the exec'd shell.

if I spawn ash w/ init=/bin/ash:
...
--  but at least I get a prompt and it seems to work.

That is very odd, I don't know why ash would work and sash does not.
Very strange indeed.

I'm not sure what the message "can't access tty; job control turned off"
means -- I'll have to get the source for ash and debug it.

This sounds like you do not have proper /dev/* populated..  i.e.
/dev/console, /dev/tty, /dev/pts, etc.  For initial system bringup you
can ignore that warning.  (However, keep in mind that ctrl-C, ctrl-Z,
etc job control will not work..)  This might also partially be a symptom
of ash starting as process 1, process 1 contains special rules in the
kernel as it is the init process.

--Mark

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

On Thursday, November 8, 2001, at 05:36  AM, Mark Pilon wrote:
 >  I'll try poking
 > around w/ gdb/abatron but am not sure how to find the exec'd shell.

I hacked up some user defined functions in gdb to let me do ps
and some other things that I found useful for kernel debugging.
I've attached my .gdbinit so you can see what I did.  Warning:
there are some processor specific bits in some of the functions,
but the ps function "should just work".

   Scott Anderson

On Thu, Nov 08, 2001 at 09:46:27AM -0600, Mark Hatle wrote:

Mark Pilon wrote:

quoted

I've got a little more info -- /bin/sash doesn't produce any
output and just sits there, echoing charachters typed.  I'll try poking
around w/ gdb/abatron but am not sure how to find the exec'd shell.

if I spawn ash w/ init=/bin/ash:
...

That is very odd, I don't know why ash would work and sash does not.
Very strange indeed.

Ah, I think I know why this might be - are you using the 2_4_devel
tree?

All static executables segfaulted before reaching main until very
recently: the 4xx's MMU makes it possible to actually enforce the
execute permission bit on pages.  Since most processors don't allow
this, however, there are heaps of bugs in userland (binutils etc.)
where pages aren't marked executable that need to be.  In this case
there was instruction just before the got that wasn't marked
executable.

For now, at least, I've disabled enforcement of the page execute
permissions, because there's just too much stuff that breaks with it
on.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson


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

David Gibson wrote:

Ah, I think I know why this might be - are you using the 2_4_devel
tree?

All static executables segfaulted before reaching main until very
recently: the 4xx's MMU makes it possible to actually enforce the
execute permission bit on pages.  Since most processors don't allow
this, however, there are heaps of bugs in userland (binutils etc.)
where pages aren't marked executable that need to be.  In this case
there was instruction just before the got that wasn't marked
executable.

For now, at least, I've disabled enforcement of the page execute
permissions, because there's just too much stuff that breaks with it
on.

What's the fix for this?  It sounds like I want to un-do that change
enforcing page execute permissions -- David, could you give me
a spot to look and a suggested patch?  anyone?

thanks,

Mark
--
Mark Pilon

Minolta-QMS
P.O. Box 37
Fallon, MT.  59326-0037

1-406-853-0433

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

On Fri, Nov 09, 2001 at 06:40:25AM -0700, Mark Pilon wrote:

David Gibson wrote:

quoted

Ah, I think I know why this might be - are you using the 2_4_devel
tree?

All static executables segfaulted before reaching main until very
recently: the 4xx's MMU makes it possible to actually enforce the
execute permission bit on pages.  Since most processors don't allow
this, however, there are heaps of bugs in userland (binutils etc.)
where pages aren't marked executable that need to be.  In this case
there was instruction just before the got that wasn't marked
executable.

For now, at least, I've disabled enforcement of the page execute
permissions, because there's just too much stuff that breaks with it
on.

What's the fix for this?  It sounds like I want to un-do that change
enforcing page execute permissions -- David, could you give me
a spot to look and a suggested patch?  anyone?

I've checked the fix into the latest linuxppc_2_4_devel.  Failing
that, look in do_page_fault() in arch/ppc/mm/fault.c, look for a test
against vma->flags & VM_EXEC, and remove it.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson


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