[parisc-linux] 715/100 data page fault and msg output

[parisc-linux] 715/100 data page fault and msg output

[Grant Grundler]

Here's the output from the 715/100 followed by some comments:

...
mem_init 0xC01667E0 0xC1000000
mem_map c0116000
&_stext c0010000
&_data_start c0071000
start_mem c0167000
Memory: 14948k available (388k kernel code, 984k data, 64k init) [c0000000,c1000000]
here
here
here
here
here
here
here
here
here
here
VM test
c007640c c0013288 c0076000
POSIX conformance testing by UNIFIX
do_basic setup 2
do_basic setup 2
interrupted with code 15, regs c0076874
IAOQ: c0067c4c c0067c50
ISR: 00000000 IOR: c00167a8 IIR: 02a008b8
ior 00000004
sp c0076ac0
c0078000 c0078000
bad pgd 00000000 at c0078000
address 00000004 (vma)
vma 00000000
bad_area
bad address 00000004

PSW  : 0004000b  GR 1 : 00000000  GR 2 : 00014de8  GR 3 : c0079000  
GR 4 : c0079000  GR 5 : c010dd48  GR 6 : c00fe000  GR 7 : c0105800  
GR 8 : 00002000  GR 9 : 00000008  GR10 : c0015e84  GR11 : fc3ffe1f  
GR12 : 00000000  GR13 : 00000001  GR14 : 0000000a  GR15 : f0000704  
GR16 : f000b858  GR17 : 00000002  GR18 : 00000000  GR19 : c00eb92c  
GR20 : 0001aa03  GR21 : f0105800  GR22 : 00000000  GR23 : 00000060  
GR24 : f0105800  GR25 : 00000001  GR26 : c00ddc8c  GR27 : c0071000  
GR28 : 00000000  GR29 : 00000000  GR30 : 00000000  GR31 : c0017840  
SR0  : 00000000  SR1  : 00000000  SR2  : 00000000  SR3  : 00000000  
SR4  : 00000000  SR5  : 00000000  SR6  : 00000000  SR7  : 00000000  
IAOQ : c0067c4c c0067c50
SHR 1: 50000800  SHR 8: 00000008  SHR 9: c00d7000  SHR16: c0076874  
SHR17: 00000002  SHR24: f0105800  SHR25: 00000001  
Kernel panic: bad address

In swapper task - not syncing
================================================

I think this is a "Data Page Fault". The processor tried to
access an address which wasn't valid in the Page directory.
Couple of things in the trap handler would help here:
o More white space - makes what to cut/paste easier to determine
o clear text describing the fault
o In this case the offending instruction and a stack trace.
o printing the invalid address, IOAQ and general registers was good
o a message about please reset the machine to restart or something
  like that.

On a different note, the kernel prints lots of useful stuff along
with plenty of garbage. As a general rule, I would like to propose
folks use file name and line number instead of "here" and "Heya".
Remember we will be debugging stuff via other folks console output
quite a bit.

thanks,
grant

ps. Alex showed me the "la la la" work around in init_task.c.
   Is anyone already working to make this a runtime check?

Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253

Re: [parisc-linux] 715/100 data page fault and msg output

[Philipp Rumpf]

> bad address 00000004
> 
> PSW  : 0004000b  GR 1 : 00000000  GR 2 : 00014de8  GR 3 : c0079000  
> GR 4 : c0079000  GR 5 : c010dd48  GR 6 : c00fe000  GR 7 : c0105800  
> GR 8 : 00002000  GR 9 : 00000008  GR10 : c0015e84  GR11 : fc3ffe1f  
> GR12 : 00000000  GR13 : 00000001  GR14 : 0000000a  GR15 : f0000704  
> GR16 : f000b858  GR17 : 00000002  GR18 : 00000000  GR19 : c00eb92c  
> GR20 : 0001aa03  GR21 : f0105800  GR22 : 00000000  GR23 : 00000060  
> GR24 : f0105800  GR25 : 00000001  GR26 : c00ddc8c  GR27 : c0071000  
> GR28 : 00000000  GR29 : 00000000  GR30 : 00000000  GR31 : c0017840  
> SR0  : 00000000  SR1  : 00000000  SR2  : 00000000  SR3  : 00000000  
> SR4  : 00000000  SR5  : 00000000  SR6  : 00000000  SR7  : 00000000  
> IAOQ : c0067c4c c0067c50
> SHR 1: 50000800  SHR 8: 00000008  SHR 9: c00d7000  SHR16: c0076874  
> SHR17: 00000002  SHR24: f0105800  SHR25: 00000001  
> Kernel panic: bad address
> 
> In swapper task - not syncing
> ================================================

This is a NULL pointer, and most probably a bug in the CVS tree that is
already fixed in my tree.  I will send a diff between the trees to the
list later.

> Couple of things in the trap handler would help here:
> o More white space - makes what to cut/paste easier to determine
> o clear text describing the fault
> o In this case the offending instruction and a stack trace.
> o printing the invalid address, IOAQ and general registers was good

basically look at what the x86 port does and implement it.

> On a different note, the kernel prints lots of useful stuff along
> with plenty of garbage. As a general rule, I would like to propose
> folks use file name and line number instead of "here" and "Heya".
> Remember we will be debugging stuff via other folks console output
> quite a bit.

Remember most of the messages will disappear soon (many of them as soon
as Alex finishes moving the tree to 2.2.12).  I do not intend to waste
my time changing anything outside of arch/parisc and include/asm-parisc
because that will mostly be replaced by the linus versions.

> ps. Alex showed me the "la la la" work around in init_task.c.
>    Is anyone already working to make this a runtime check?

you cannot.  not without major pain at least


	Philipp Rumpf

Re: [parisc-linux] 715/100 data page fault and msg output

[LaMont Jones]

> IAOQ: c0067c4c c0067c50
> ISR: 00000000 IOR: c00167a8 IIR: 02a008b8
> ior 00000004
> o In this case the offending instruction and a stack trace.

Interestingly, IIR (the interupting instruction register) contains
mfctl   ior,arg2, which is not what we want...  Likewise IOR (as
opposed to ior) also looks suspect.  I would wager that someone is
not saving the I* registers correctly...

lamont

Re: [parisc-linux] 715/100 data page fault and msg output

[Philipp Rumpf]

> Interestingly, IIR (the interupting instruction register) contains
> mfctl   ior,arg2, which is not what we want...  Likewise IOR (as
> opposed to ior) also looks suspect.  I would wager that someone is
> not saving the I* registers correctly...

we don't save them at all, but directly read them.  Of course, printing them
doesn't make any sense (except for debugging the interruption code).

	Philipp Rumpf

Re: [parisc-linux] 715/100 data page fault and msg output

[Grant Grundler]

Philipp Rumpf wrote:

> This is a NULL pointer, and most probably a bug in the CVS tree that is
> already fixed in my tree.  I will send a diff between the trees to the
> list later.

Cool. Thanks!

> 
> > Couple of things in the trap handler would help here:
> > o More white space - makes what to cut/paste easier to determine
> > o clear text describing the fault
> > o In this case the offending instruction and a stack trace.
> > o printing the invalid address, IOAQ and general registers was good
> 
> basically look at what the x86 port does and implement it.

Ok - any volunteers?


...
> > ps. Alex showed me the "la la la" work around in init_task.c.
> >    Is anyone already working to make this a runtime check?
> 
> you cannot.  not without major pain at least

That didn't answer my question.

The right person might be able fix this without major pain.
I don't think I'm that person but I could look at it anyway
and then try to find the right person. Another OS doesn't have
this problem and obviously has solved it.

thanks,
grant

Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253

Re: [parisc-linux] 715/100 data page fault and msg output

[Philipp Rumpf]

> > > Couple of things in the trap handler would help here:
> > > o More white space - makes what to cut/paste easier to determine
> > > o clear text describing the fault
> > > o In this case the offending instruction and a stack trace.
> > > o printing the invalid address, IOAQ and general registers was good
> > 
> > basically look at what the x86 port does and implement it.
> 
> Ok - any volunteers?

I am a low-priority volunteer, i.e. if noone else does it I'll do it anyway
one day.

> > > ps. Alex showed me the "la la la" work around in init_task.c.
> > >    Is anyone already working to make this a runtime check?
> > 
> > you cannot.  not without major pain at least
> 
> That didn't answer my question.
> 
> The right person might be able fix this without major pain.
> I don't think I'm that person but I could look at it anyway
> and then try to find the right person. Another OS doesn't have
> this problem and obviously has solved it.

 - we could fix our binutils and use elf instead of som.  we'll have to do
   so anyway at one point but it's a major piece of boring work

 - we could runtime-relocate init_task_union.  major pain because we would
   have to change assembly

 - we could reduce the size of task_struct and stack to 4 KB

 - we could change the way Linux allocates the kernel stack

 - we could detect at build time that init_task_union isn't aligned and work
   around it with makefile / ld magic.

Re: [parisc-linux] 715/100 data page fault and msg output

[Ryan Bradetich]

> > > ps. Alex showed me the "la la la" work around in init_task.c.
> > >    Is anyone already working to make this a runtime check?

Grant:

I'm working on getting the kernel to boot/load on a C200... would you mind
explaining the "la la la" work around in init_task.c so I'll know when I get
to that point?

Thanks,
-Ryan

[parisc-linux] C200 support

[Grant Grundler]

Ryan Bradetich wrote:
> I'm working on getting the kernel to boot/load on a C200...

Ryan,
C200+ has a PA-8200 processor (PA 2.0 Arch) and C200 had the previous
PA 2.0 processor in it. Haven't you had problems since this port
(to date) is focused on PA1.1 architecture?

I'm certain PA2.0 will be supported in the future but not today.
I don't want to discourage you but also don't want you to
burn out trying to make this work...

grant


Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253

Re: [parisc-linux] 715/100 data page fault and msg output

[LaMont Jones]

> we don't save them at all, but directly read them.  Of course, printing them
> doesn't make any sense (except for debugging the interruption code).

Reading them when PSW.Q=1 is undefined, and it sounds like that's where the
problem is coming from....  IIR should have had a load or store in it for
Grant's problem...  But that has to get stored before going virtual to
handle the trap...

lamont

Re: [parisc-linux] 715/100 data page fault and msg output

[Philipp Rumpf]

> > we don't save them at all, but directly read them.  Of course, printing them
> > doesn't make any sense (except for debugging the interruption code).
> 
> Reading them when PSW.Q=1 is undefined, and it sounds like that's where the
> problem is coming from....

erm.  yes, I know that.  Yes, I said it doesn't make any sense.

> IIR should have had a load or store in it for Grant's problem...

Grant's problem is most likely solved.  And no, there is no reason to save
IIR right now (there might be one when we have to find out whether a read or
write failed).

	Philipp Rumpf

Re: C200 support

[Ryan Bradetich]

Grant Grundler wrote:

> Ryan Bradetich wrote:
> > I'm working on getting the kernel to boot/load on a C200...
>
> Ryan,
> C200+ has a PA-8200 processor (PA 2.0 Arch) and C200 had the previous
> PA 2.0 processor in it. Haven't you had problems since this port
> (to date) is focused on PA1.1 architecture?
>

Yep,  I have the C200+ with the PA-8200 processor, and yes ... I've been
having lots of problems with the port, but I'm slowly working through
them :)  Unfortunately, my parisc assembly/linux internals is really,
really weak, but this gives me a good chance to learn both.


>
> I'm certain PA2.0 will be supported in the future but not today.
> I don't want to discourage you but also don't want you to
> burn out trying to make this work...

Nah, I  probably won't get burned out, but will probably keep asking
quite a few questions as I continue to learn.

>
> grant
>
> Grant Grundler
> Communications Infrastructure Computer Operations
> +1.408.447.7253

Re: [parisc-linux] 715/100 data page fault and msg output

[Grant Grundler]

Philipp Rumpf wrote:
...
> > IIR should have had a load or store in it for Grant's problem...
> 
> Grant's problem is most likely solved.

When will I see a "likely solution"?

I'm still clueless to what is causing the data page fault and can't
make forward progress on Dino support.

(Hint: I have a card-mode Dino installed to exercise the basic code.)


thanks,
grant

Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253

[parisc-linux] 715/80 problems

[Hannu Martikka]

Hei!


With 715/80 I get following:

Boot
:disk(....)/stand/vmlinux

GRs

0x00000000
...
	<bunch of HEX-values>
CRs

	<bunch of HEX-values>
SRs

	<bunch of HEX-values>
OTHER

	<bunch of HEX-values>

and then nothing...
It should be plain 715 but I have addon X.25 card on this machine (EISA?)

- Goodi
"The linuX Files -- The Source is Out There."
ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤º°

Re: [parisc-linux] 715/80 problems

[Philipp Rumpf]

> With 715/80 I get following:
> Boot
> :disk(....)/stand/vmlinux

you might want to try to boot via tftp / bootp as this is what most of us do
and it seems to work for us.

	Philipp Rumpf

Re: [parisc-linux] 715/80 problems

[Grant Grundler]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

Hannu Martikka wrote:
> Hei!
> 
> 
> With 715/80 I get following:
> 
> Boot
> :disk(....)/stand/vmlinux
> 

Hannu/Goodi,
You didn't get any messages about a bad address here?

Dumping the GRs/CRs/SRs suggests a SW fault which can't be
handled...but the linux kernel needs to learn how to dump
more useful information.

BTW, those "<bunch of HEX-values>" mean something to various
people on the list. If you can collect (and post) all output
via serial console starting with the "Boot" message, others
on this list might be able to help.

> GRs
> 
> 0x00000000
> ...
> 	<bunch of HEX-values>
> CRs
> 
> 	<bunch of HEX-values>
> SRs
> 
> 	<bunch of HEX-values>
> OTHER
> 
> 	<bunch of HEX-values>
> 
> and then nothing...
> It should be plain 715 but I have addon X.25 card on this machine (EISA?)

I think the EISA is ignored for now...

grant

> 
> - Goodi
> "The linuX Files -- The Source is Out There."
> ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤º°
> 
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.
> 

Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253

Re: [parisc-linux] 715/80 problems

[Hannu Martikka]

On Wed, 22 Sep 1999, Philipp Rumpf wrote:

> > With 715/80 I get following:
> > Boot
> > :disk(....)/stand/vmlinux
> 
> you might want to try to boot via tftp / bootp as this is what most of us do
> and it seems to work for us.
What's the difference? I mean why should it be different?
I guess tftp/bootp uses the Image (make Image) and IPL can use vmlinux
(make vmlinux) kernel.

> 	Philipp Rumpf
- Goodi
"The linuX Files -- The Source is Out There."
ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤º°

Re: [parisc-linux] 715/80 problems

[Philipp Rumpf]

> What's the difference? I mean why should it be different?
> I guess tftp/bootp uses the Image (make Image) and IPL can use vmlinux
> (make vmlinux) kernel.

It can't (or at least I don't know it can).  The kernel image has to be
loaded by a boot loader, and there is reason to believe it has to be our
boot loader.

 	Philipp Rumpf

Re: [parisc-linux] 715/80 problems

[Grant Grundler]

Philipp Rumpf wrote:
> Hannu Martikka wrote:
> > With 715/80 I get following:
> > Boot
> > :disk(....)/stand/vmlinux
> 
> you might want to try to boot via tftp / bootp as this is what most of us do
> and it seems to work for us.

Goodi,
Are you using HP-UX boot loader?

To boot from disk, one should do "make Image" and dd the Image to disk.
This will trash the HP-UX file system so only do this on a spare disk!
The loader used is then from the parisc-linux source tree.

grant

Re: [parisc-linux] 715/80 problems

[Hannu Martikka]

On Wed, 22 Sep 1999, Grant Grundler wrote:

> Philipp Rumpf wrote:
> > Hannu Martikka wrote:
> > > With 715/80 I get following:
> > > Boot
> > > :disk(....)/stand/vmlinux
> > 
> > you might want to try to boot via tftp / bootp as this is what most of us do
> > and it seems to work for us.
> 
> Goodi,
> Are you using HP-UX boot loader?
I was... It used to work (at the time when kernel didn't... :)

> To boot from disk, one should do "make Image" and dd the Image to disk.
> This will trash the HP-UX file system so only do this on a spare disk!
> The loader used is then from the parisc-linux source tree.
I setup the tftp/bootp server and now I can boot my 715/80 from lan.
Last thing it says is "urgh" and then it stays in for(;;). I cannot say
wether that is good or bad :)

> grant
- Goodi
"The linuX Files -- The Source is Out There."
ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤º°

Re: [parisc-linux] 715/80 problems

[Hannu Martikka]

On Wed, 22 Sep 1999, Grant Grundler wrote:

> Hannu Martikka wrote:
> > Hei!
> > With 715/80 I get following:
> > 
> > Boot
> > :disk(....)/stand/vmlinux
> > 
> 
> Hannu/Goodi,
> You didn't get any messages about a bad address here?
Nope. First thing that showed up was "GRs".

> Dumping the GRs/CRs/SRs suggests a SW fault which can't be
> handled...but the linux kernel needs to learn how to dump
> more useful information.
> 
> BTW, those "<bunch of HEX-values>" mean something to various
> people on the list. If you can collect (and post) all output
> via serial console starting with the "Boot" message, others
> on this list might be able to help.
I was using the IPL/HPUX loader to start kernel. Are you still interested?
It now works with tftp/bootp.

> Grant Grundler
> Communications Infrastructure Computer Operations
> +1.408.447.7253
- Goodi
"The linuX Files -- The Source is Out There."
ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤º°

Re: [parisc-linux] 715/80 problems

[Alex deVries]

Philipp Rumpf wrote:
> 
> > With 715/80 I get following:
> > Boot
> > :disk(....)/stand/vmlinux
> 
> you might want to try to boot via tftp / bootp as this is what most of us do
> and it seems to work for us.

There's definitely a problem with booting off of a disk, and I'm not
sure what the problem really is.  It'd be great if someone could look
into this, I know we're not implementing the entire LIF header.

Has *anyone* been able to boot from disk?

- Alex

-- 
Alex deVries
Vice President of Engineering
The Puffin Group