Re: [parisc-linux] One more step: Interruption (trap) 18 on 9000/720

Re: [parisc-linux] One more step: Interruption (trap) 18 on 9000/720

[Christoph Plattner]

Thank you for the answer !

I will check that point and I hope my skills are high enough 
for all that.

Further, can you tell me, how to use and where I can find
the kernel debugger stuff. I am used to handle a modified
gdb debuging parts of chorus kernel (on intel machines) in
my job, so I think I should handle that. I saw (as far
this is right) that the kernel debug support is new in
2.4 kernel (partially 2.3) and I am interested in that, as
I often write device drivers (I also want use this for HP
and for intel).

The `strace' is not running with the new stuff. Will there 
be an update. (I tried the current CVS version, but I have
built probles. Many of them I tried to fix. But in process.c
there were problems in basic structures.

And now a very important question:
---------------------------------

You seem to be the right man asking this. I also have an
E55 server (9000/856) with those propriatary HP interfaces.
For me the SCSI controller and the 8-port serial multiplxer
(used for serial console on port-0) are the important
key points. Is there no possibility to get them running ??
Is there really no documentation, etc...

Can I use the PDC console as system console
(not to have "Switching from PDC console..."), so that
I can run Linux NFS based via the PDC console ?

I hope you can help.

With friendly regards

	Christoph




John Marvin wrote:
> 
> >
> > or whatever my first process is. I have instrumented the kernel code
> > and added the output of the code number (a good idea to have this
> > fix in the kernel !) and I saw:
> >
> >         code=18
> >
> > So I have the code 18 (decimal). In the PA RISC 1.1 manual (your link)
> > I saw following description:
> >
> >         18  Data memory protection trap / Unaligned data reference trap
> >
> > So what does this mean here. An alignment problem ?
> > Why is this code not handled in the switch/case ?
> >
> We have done very little testing on machines with PCXS processors. PCXS
> processors are the earliest cpu's that conformed to the PARISC 1.1
> architecture specification, and therefore are the earliest processors that
> we will probably ever support. Anything earlier was PARISC 1.0 based, and
> I doubt we will every support PARISC 1.0 based machines.
> 
> PCXS has a variety of unique differences from some of the later parisc
> cpu's, and you just ran into one of them. Trap type 18 was generated
> by PARISC 1.0 based cpu's primarily. PCXS is the only PARISC 1.1 cpu
> that generates this type of trap. Trap 18 was replaced by Trap 26,
> 27 & 28 in all later cpu's.  The reason is that a Trap 18 has three
> possible causes, and it was a lot better to have three different traps
> for those different causes. Those three causes are:
> 
>     Data Memory Access Rights Trap (Now trap type 26)
>     Data Memory Protection Id Trap (Now trap type 27)
>     Unaligned Data Reference Trap  (Now trap type 28)
> 
> So, the correct fix is going to require code that can test for each of
> these three possibilities, and then do the right thing (e.g. an
> unaligned fault can be checked for by using the iir to determine the
> access size, and then comparing that to the ior to see if the address
> is properly aligned).
> 
> However, there may be a quick workaround you can try.  Currently we don't
> enable protection id checking (we will eventually), so it should be
> impossible to get a Data Memory Protection Id Trap.  In most cases we
> should only get an Unaligned Data Reference Trap if there is a bug.
> However there is a known bug right now (a fix is in progress) in the
> pthreads support which might cause this trap to be generated on a PCXS
> processor.  The only trap that should happen in the normal execution of
> the kernel is a Data Memory Access Rights Trap, which will happen every
> time there is a copy-on-write fault.
> 
> So, the quick workaround might be to just add a "case 18" where you
> find "case 15" and "case 26" in handle_interruption. The problem with
> this workaround is that if you do get an Unaligned Data Reference
> fault you will just hang the kernel, because you will keep calling
> do_page_fault() for a problem that do_page_fault() can't fix.
> 
> > I always use (I think the 32bit code). Have I set to a parisc64 ?
> > How can I influence this ?
> > Which kind of CPU is this in the 720 model ? (I know a 50MHz PA RISC ..)
> >
> 
> PARISC 1.1 processors are incapable of running in 64 bit mode. As I
> mentioned above the processor in a 720 is a PCXS processor. PCXS is
> the internal name for a PA7000 processor.
> 
> John Marvin
> jsm@fc.hp.com

-- 
  +--------V--------+	Christoph.Plattner@alcatel.at
  |  A L C A T E L  |	-----------------------------
  +-----------------+	Phone: +43 1 27722 3706	
         T A S		Fax:   +43 1 27722 3955

Re: [parisc-linux] One more step: Interruption (trap) 18 on 9000/720

[Grant Grundler]

Christoph Plattner wrote:
> Further, can you tell me, how to use and where I can find
> the kernel debugger stuff.

There is no kernel debugger (yet). I started working on one last year
based on "KWDB" from HPUX. I've added the kernel hooks (CONFIG_KWDB).
But I (a) didn't get it working and (b) didn't get permission to publish
the KWDB base. My advice is for someone to take the SGI KDB and make it
work for parisc-linux and changing CONFIG_KWDB to CONFIG_KDB.

...
> And now a very important question:
> ---------------------------------
> 
> You seem to be the right man asking this. I also have an
> E55 server (9000/856) with those propriatary HP interfaces.
> For me the SCSI controller and the 8-port serial multiplxer
> (used for serial console on port-0) are the important
> key points. Is there no possibility to get them running ??
> Is there really no documentation, etc...

This is explained in the FAQ or HWDB "introduction" someplace.
Someone *in* HP has to care enough to review the documentation
and get it past the lawyers. I don't. Search the parisc-linux
mail archive for "SPIFI" if you want more...

grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] One more step: Interruption (trap) 18 on 9000/720

[Matthew Wilcox]

On Wed, Jan 24, 2001 at 08:50:12AM -0800, Grant Grundler wrote:
> There is no kernel debugger (yet). I started working on one last year
> based on "KWDB" from HPUX. I've added the kernel hooks (CONFIG_KWDB).
> But I (a) didn't get it working and (b) didn't get permission to publish
> the KWDB base. My advice is for someone to take the SGI KDB and make it
> work for parisc-linux and changing CONFIG_KWDB to CONFIG_KDB.

FYI, after my PA-RISC talk at linux.conf.au, Keith Owens expressed
interest in porting KDB to Linux/PARISC.  He's on holiday just now but
he'll investigate further after he gets back.

Grant, do you think it'd be worth removing the KWDB bits?

-- 
Revolutions do not require corporate support.

[parisc-linux] KWDB vs KDB

[Grant Grundler]

Matthew Wilcox wrote:
> On Wed, Jan 24, 2001 at 08:50:12AM -0800, Grant Grundler wrote:
> FYI, after my PA-RISC talk at linux.conf.au, Keith Owens expressed
> interest in porting KDB to Linux/PARISC.  He's on holiday just now but
> he'll investigate further after he gets back.
> 
> Grant, do you think it'd be worth removing the KWDB bits?

Should KDB not need something with CONFIG_KWDB around it, Keith
is certainly welcome to remove the CONFIG_KWDB usage/code.
I'm pretty sure the same hooks will be needed for KDB.
Just rename CONFIG_KWDB to CONFIG_KDB.

later,
grant

Re: [parisc-linux] One more step: Interruption (trap) 18 on 9000/720

[Christoph Plattner]

Hello, again.

What does this `SPIFI' mean?
Is this a name of a person, or a technical expression, ... ?

I read something at the E55 of "undocumented drivers" and so
on, but I hoped somebody has a solution, and I myself am interested
in helping writing drivers for that E55, as I really want to use
it inclusive all 8 serial ports and SCSI !

With friendly regards
	Christoph




Grant Grundler wrote:
> 
> Christoph Plattner wrote:
> > Further, can you tell me, how to use and where I can find
> > the kernel debugger stuff.
> 
> There is no kernel debugger (yet). I started working on one last year
> based on "KWDB" from HPUX. I've added the kernel hooks (CONFIG_KWDB).
> But I (a) didn't get it working and (b) didn't get permission to publish
> the KWDB base. My advice is for someone to take the SGI KDB and make it
> work for parisc-linux and changing CONFIG_KWDB to CONFIG_KDB.
> 
> ...
> > And now a very important question:
> > ---------------------------------
> >
> > You seem to be the right man asking this. I also have an
> > E55 server (9000/856) with those propriatary HP interfaces.
> > For me the SCSI controller and the 8-port serial multiplxer
> > (used for serial console on port-0) are the important
> > key points. Is there no possibility to get them running ??
> > Is there really no documentation, etc...
> 
> This is explained in the FAQ or HWDB "introduction" someplace.
> Someone *in* HP has to care enough to review the documentation
> and get it past the lawyers. I don't. Search the parisc-linux
> mail archive for "SPIFI" if you want more...
> 
> grant
> 
> Grant Grundler
> Unix Systems Enablement Lab
> +1.408.447.7253
> 
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.

-- 
-------------------------------------------------------------------------
private:	christoph.plattner@dot.at
company:	christoph.plattner@alcatel.at

[parisc-linux] One more step: Interruption (trap) 18 on 9000/720

[Christoph Plattner]

Hallo PA RISC hackers !

I mentioned before, that I have problems using my Apollo 700 (9000/720)
with the Linux here. I build a new cross tool chain and a new
kernel + palo (all from 13.Jan 2001) but I always have the problem
of that always repeated error:

handler_interruption() pid=1 command='init'

or whatever my first process is. I have instrumented the kernel code
and added the output of the code number (a good idea to have this
fix in the kernel !) and I saw:

        code=18

So I have the code 18 (decimal). In the PA RISC 1.1 manual (your link)
I saw following description:

        18  Data memory protection trap / Unaligned data reference trap

So what does this mean here. An alignment problem ?
Why is this code not handled in the switch/case ?

I always use (I think the 32bit code). Have I set to a parisc64 ?
How can I influence this ?
Which kind of CPU is this in the 720 model ? (I know a 50MHz PA RISC ..)

I hope anybody can help here

        Christoph




-------------------------------------------------------------------
private:        christoph.plattner@dot.at
company:        christoph.plattner@alcatel.at