[parisc-linux] C360 shellprompt

[parisc-linux] C360 shellprompt

[Philipp Rumpf]

Just so you all know, we get to a shell prompt on the C360 after the
changes which I'm about to commit (blame slow dialup lines).  I would
like to know whether we get to a prompt on other PA2.0 machines as well.

When testing, please keep in mind most "kernel doesn't print anytihng"
problems are problems in the .config rather than kernel bugs.  Start
with the defconfig and modify as little as possible.  Also, the most
likely cause for non-reproducible failures is page colouring problems
so try 3-4 times.

Anyway, on Lasi-based machines such as the C360 you should be able to
do anything you can do on the 712 right now (-ls, fork() but not exec(),
rebooting the machine with SysRq-B), just a lot faster.

	Philipp Rumpf

[parisc-linux] C360 shellprompt

[Philipp Rumpf]

Just so you all know, we get to a shell prompt on the C360 after the
changes which I'm about to commit (blame slow dialup lines).  I would
like to know whether we get to a prompt on other PA2.0 machines as well.

When testing, please keep in mind most "kernel doesn't print anytihng"
problems are problems in the .config rather than kernel bugs.  Start
with the defconfig and modify as little as possible.  Also, the most
likely cause for non-reproducible failures is page colouring problems
so try 3-4 times.

Anyway, on Lasi-based machines such as the C360 you should be able to
do anything you can do on the 712 right now (-ls, fork() but not exec(),
rebooting the machine with SysRq-B), just a lot faster.

	Philipp Rumpf

Re: [parisc-linux] C360 shellprompt

[Matthew Wilcox]

On Tue, Jan 11, 2000 at 03:53:21PM +0100, Philipp Rumpf wrote:
> Just so you all know, we get to a shell prompt on the C360 after the
> changes which I'm about to commit (blame slow dialup lines).  I would
> like to know whether we get to a prompt on other PA2.0 machines as well.

On the C3000, there is a problem with calling the pdc, as we discussed
offline.  With the calls to the PDC commented out, we get past the
`POSIX Conformance Testing by UNIFIX' line:

after __k_t (1)
554
556
558
after __k_t (0)
766
618
628
630
641
645
651
bad magic 6a930530 (should be c0030a80), wq bug, forcing oops.


On the L-class (ok, just for a giggle, and the room was too cold :-) :

Transferring control to kernel. (At entry point 0x00010000)
!.
************* SYSTEM ALERT **************
SYSTEM NAME: uninitialized
DATE: 01/12/2000 TIME: 21:22:19
ALERT LEVEL: 7 = reserved

REASON FOR ALERT
SOURCE: 0 = unknown, no source stated
SOURCE DETAIL: 0 = unknown, no source stated   SOURCE ID: FF
PROBLEM DETAIL: 0 = no problem detail

LEDs:  RUN      ATTENTION     FAULT     REMOTE     POWER
       FLASH    FLASH         FLASH     OFF        ON

0x0000307000FF6292 00000000 00000000 - type  0 = Data Field Unused
0x5800387000FF6292 00006400 0C151613 - type 11 = Timestamp 01/12/2000 21:22:19
A: ack read of this entry - X: Disable all future alert messages
Anything else skip redisplay the log entry
->Choice:

which is not something I've seen before.  Is this at all familiar to
someone else?  This is presumably being generated by the PAT PDC, so
maybe someone with N-class experience could tell me a bit about it?

Re: [parisc-linux] C360 shellprompt

[Matthew Wilcox]

On Wed, Jan 12, 2000 at 04:41:52PM -0500, Matthew Wilcox wrote:
[...]
> bad magic 6a930530 (should be c0030a80), wq bug, forcing oops.

Found this one.  It's my fault in the HIL driver.  Turn off CONFIG_HIL
and things progress further:

execve /sbin/init c00df008 c00df030
do_execve
reading c005cf70 cffe8808 cffe85c8 128
pgc bad case
getting new pages ...
got c144c040 to c144c43c
gcp 00000000 19 0 = c144c040 (c005cc7c)
readpage: c006ddc8
page_ok
returned 128
02100108 05124000 00000000 00000000
00000000 00000000 000039c3 00000080
000000b4 00045574 40006d38 00000138
00000004 000001c8 00000013 000004fc
00000000 000004fc 000001e8 000004c0
00000003 000006e4 00000000 000006e4
00000000 000006e4 00000000 000006e4
00000000 00045000 00000574 4702100b
gcp 2001f000 19 0 = c144c43c (c007277c)

[ i thought that bit might be of interest ]

map_som_binary
do_mmap cff260e0 00001000 0003f000 00000005 00001806 00000000
miscoloured mmap
do_mmap cff260e0 40001000 00006000 00000007 00001806 0003f000
miscoloured mmap
do_mmap 00000000 40007000 0000f000 00000007 00000006 00000000
miscoloured mmap

which looks slightly offputting.

stack_base 2001f000 cff1f000
mem_map disagrees with c144c43c at 2001f000
set_pte cff2007c 0ff1f047
create_som_tables
sp 2001ffd8
hey.

the `disagrees' part made me snip this little section out.

The last lines before I get nothing more reads:

gcp 0000e000 19 0 = c144c3f8 (c005bb9c)
pgc bad case
getting new pages ...
got c144b7c0 to c144bbbc
gcp 0000f000 19 0 = c144bbbc (c005bb9c)
gcp 00003000 21 0 = c144b88c (c005d550)
new_page c144b88c flags 00000000
new_page c144b88c flags 00000000
cfef3000 cff12000
new_page c144b88c flags 00000000
new_page c144b88c flags 00000000
set_pte cff0f00c 0fef300b

so i don't actually get a prompt on the c3k, but we're closer.
On the A180, it stops right before the `hey'.  It has the same
value for `sp' as the C3k.