[parisc-linux] Re: [parisc-linux-cvs] linux carlos

[parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Carlos O'Donell]

On Wed, Aug 20, 2003 at 01:29:19PM -0600, Carlos O'Donell wrote:
> CVSROOT:	/var/cvs
> Module name:	linux
> Changes by:	carlos	03/08/20 13:29:19
> 
> Modified files:
> 	arch/parisc/kernel: entry.S 
> 
> Log message:
> itlb_fault optmizaztion

Lamont made a good catch and we optimized the standard case in the itlb
fault fast path, keeping the CPU's forward branch prediction working in
our favour. As such our numbers for various syscalls (LMBENCH tests)
have become more stable from call to call. The best number is our 'page
fault' which has shown a ~10x speedup :) It used to be 130 microseconds
+/- 100 microseconds, and is now consistently ~13 microseconds.

I ran 30 LMBENCH runs, 10 each for the following configurations:
1- ITLB Optimization
2- ITLB Optimization + Removal of a register interlock on the fast path
3- No ITLB Optimization

I've applied #2 to our CVS. Please tell me if anyone sees any breakage.
This runs fine on my C3K.

Cheers,
Carlos.

Index: entry.S
===================================================================
RCS file: /var/cvs/linux/arch/parisc/kernel/entry.S,v
retrieving revision 1.98
diff -u -p -r1.98 entry.S
--- entry.S	9 Dec 2002 06:09:08 -0000	1.98
+++ entry.S	12 Aug 2003 03:49:04 -0000
@@ -1469,8 +1469,7 @@ itlb_miss_20w:
 	mfctl           %cr25,ptp	/* load user pgd */
 
 	mfsp            %sr7,t0		/* Get current space */
-	or,*=           %r0,t0,%r0      /* If kernel, nullify following test */
-	cmpb,*<>,n      t0,spc,itlb_fault /* forward */
+	cmpb,<>,n	t0,spc,itlb_user_fault_20w /* forward */
 
 	/* First level page table lookup */
 
@@ -1535,8 +1534,7 @@ itlb_miss_11:
 	mfctl           %cr25,ptp	/* load user pgd */
 
 	mfsp            %sr7,t0		/* Get current space */
-	or,=            %r0,t0,%r0	/* If kernel, nullify following test */
-	cmpb,<>,n       t0,spc,itlb_fault /* forward */
+	cmpb,<>,n	t0,spc,itlb_user_fault_11 /* forward */
 
 	/* First level page table lookup */
 
@@ -1551,6 +1549,10 @@ itlb_miss_common_11:
 	sh2addl 	 t0,ptp,ptp
 	ldi		_PAGE_ACCESSED,t1
 	ldw		 0(ptp),pte
+
+	/* Running parallel, taken from below 'zdep0' */
+	zdep            spc,30,15,prot  /* create prot id from space */
+
 	bb,>=,n 	 pte,_PAGE_PRESENT_BIT,itlb_fault
 
 	/* Check whether the "accessed" bit was set, otherwise do so */
@@ -1559,7 +1561,7 @@ itlb_miss_common_11:
 	and,<>		t1,pte,%r0	/* test and nullify if already set */
 	stw		t0,0(ptp)	/* write back pte */
 
-	zdep            spc,30,15,prot  /* create prot id from space */
+	/* zdep0 moved back */
 	dep             pte,8,7,prot    /* add in prot bits from pte */
 
 	extru,=		pte,_PAGE_NO_CACHE_BIT,1,r0
@@ -1602,8 +1604,7 @@ itlb_miss_20:
 	mfctl           %cr25,ptp	/* load user pgd */
 
 	mfsp            %sr7,t0		/* Get current space */
-	or,=            %r0,t0,%r0	/* If kernel, nullify following test */
-	cmpb,<>,n       t0,spc,itlb_fault /* forward */
+	cmpb,<>,n	t0,spc,itlb_user_fault_20	/* forward */
 
 	/* First level page table lookup */
 
@@ -1882,6 +1883,37 @@ kernel_bad_space:
 dbit_fault:
 	b               intr_save
 	ldi             20,%r8
+
+/* The following three labels relate to an optimization in the itlb handler.
+   itlb_user_fault_20w:
+   itlb_user_fault_20:
+   itlb_user_fault_11:
+   We keep the CPU jumping fwd/bkwd in the common case, and the uncommon case
+   has the cmpb fail (no jump) and thus branch prediction failing. */
+
+#ifdef __LP64__
+itlb_user_fault_20w:
+	/* User tlb missed for other than his own space. Optimization. */
+	cmpb,=		%r0,t0,itlb_miss_common_20w /* backward */
+	nop
+#else
+itlb_user_fault_20:
+	/* User tlb missed for other than his own space. Optimization. */
+	cmpb,=		%r0,t0,itlb_miss_common_20 /* backward */
+	nop
+
+/* FALL THROUGH - We don't care if we run the test twice. If someone
+                  asks to have the "user is faulting death" path optimal
+                  then they should seek help. */
+
+itlb_user_fault_11:
+	/* User tlb missed for other than his own space. Optimization. */
+	cmpb,=		%r0,t0,itlb_miss_common_11 /* backward */
+	nop
+#endif
+
+/* FALL THROUGH - We have a real itlb_fault from one of the above three
+                  label sequences */
 
 itlb_fault:
 	b               intr_save

RE: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Joel Soete]

>Lamont made a good catch and we optimized the standard case in the itlb
>fault fast path, keeping the CPU's forward branch prediction working in
>our favour. 

That is the very fine state of the art :)

>As such our numbers for various syscalls (LMBENCH tests)
>have become more stable from call to call. The best number is our 'page
>fault' which has shown a ~10x speedup :) It used to be 130 microseconds
>+/- 100 microseconds, and is now consistently ~13 microseconds.

Congratulation, I will try it also on the N (64bits)

Thanks again,
    Joel


-------------------------------------------------------------------------
Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous!
http://reg.tiscali.be/default.asp?lg=fr 

Re: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Grant Grundler]

On Fri, Aug 29, 2003 at 05:59:53PM +0200, Joel Soete wrote:
> I just noticed the two following loops:
> flush_data_cache_local:

Note the names of the routines!
ie should only be called when we know only the local CPU is touching
data that needs to be flushed. This sounds like a risky
strategy to me given prefetching can occur to page
that's mapped cacheable.

> Do you think that could be there where the pb occurs?

I don't. There are likely other problems hidden there though.

grant

RE: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Joel Soete]

>If you use fdc, fic, or pdc then they are broadcast to other
>processors, but fdce and fice are not.

Hi Jim and al,

I just noticed the two following loops:
flush_data_cache_local:
[...]

fdmanyloop:                                     /* Loop if LOOP >= 2 */
        ADDIB>          -1,%r31,fdmanyloop      /* Adjusted inner loop decr
*/
        fdce            0(%sr1,%arg0)
        fdce,m          %arg1(%sr1,%arg0)       /* Last fdce and addr adjust
*/
        movb,tr         %arg3,%r31,fdmanyloop   /* Re-init inner loop count
*/
        ADDIB<=,n       -1,%arg2,fdsync         /* Outer loop decr */

fdoneloop:                                      /* Loop if LOOP = 1 */
        ADDIB>          -1,%arg2,fdoneloop      /* Outer loop count decr
*/
        fdce,m          %arg1(%sr1,%arg0)       /* Fdce for one loop */

fdsync:
        syncdma
        sync
        mtsm    %r22
        bv      %r0(%r2)
        nop
        .exit

        .procend

[...]

flush_instruction_cache_local:
[...]

fimanyloop:                                     /* Loop if LOOP >= 2 */
        ADDIB>          -1,%r31,fimanyloop      /* Adjusted inner loop decr
*/
        fice            0(%sr1,%arg0)
        fice,m          %arg1(%sr1,%arg0)       /* Last fice and addr adjust
*/
        movb,tr         %arg3,%r31,fimanyloop   /* Re-init inner loop count
*/
        ADDIB<=,n       -1,%arg2,fisync         /* Outer loop decr */

fioneloop:                                      /* Loop if LOOP = 1 */
        ADDIB>          -1,%arg2,fioneloop      /* Outer loop count decr
*/
        fice,m          %arg1(%sr1,%arg0)       /* Fice for one loop */

fisync:
        sync
        bv      %r0(%r2)
        nop
        .exit

        .procend


Do you think that could be there where the pb occurs?

Thanks for advise,
    Joel

-------------------------------------------------------------------------
Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous!
http://reg.tiscali.be/default.asp?lg=fr 

RE: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Joel Soete]

Hi Jim,

Well come :)
> I haven't really been following this thread, so I don't know what
>problem you're actually trying to solve, but I'd like to point out a few
>aspects of the PA-RISC processor architecture.
>
To be short, the pa linux kernel boot well on A model as SMP (Multiprocessor
mode) but panic on L/N model. And a pb in tlb management is suspected.

>Comments mixed with the original text, below.
>
> -- Jim
>   
>> HP Itanium/PA-RISC Processor Architect

>If you use fdc, fic, or pdc, then they are broadcast to other
>processors, but fdce and fice are not.

Thanks I will check if such a code is used.

>While you can use ldda and stda to access memory using absolute
>(physical) addresses instead of virtual, these instructions do *not*
>bypass the cache.  And because PA processors use virtually-indexed
>caches, the rules for mixing virtual and absolute accesses, and have
>them all remain cache-coherent, are complicated.  If you really need to
>do this, then you'll have to read and understand all of Appendix F, "TLB
>and Cache Control", in the PA-RISC 2.0 Architecture manual (the "Kane"
>book).

Yes, very accurate reference, but imo it is not a course on PA-RISC asm (I
mean, as a beginner, as i am, would like to find with some trial example
showing what is good and trivial errors to not commit).

Thanks for your clear comments,
    Joel


-------------------------------------------------------------------------
Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous!
http://reg.tiscali.be/default.asp?lg=fr 

RE: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Jim Hull]

I haven't really been following this thread, so I don't know what
problem you're actually trying to solve, but I'd like to point out a few
aspects of the PA-RISC processor architecture.

Comments mixed with the original text, below.

 -- Jim
    HP Itanium/PA-RISC Processor Architect

> -----Original Message-----
> From: parisc-linux-admin@lists.parisc-linux.org 
> [mailto:parisc-linux-admin@lists.parisc-linux.org] On Behalf 
> Of Joel Soete
> Sent: Thursday, August 28, 2003 9:08 AM
> To: Grant Grundler
> Cc: parisc-linux@lists.parisc-linux.org
> Subject: Re: [parisc-linux] Re: [parisc-linux-cvs] linux carlos
> 
> 
> >
> >no.
> >IIRC instructions for purging the cache are broadcast to other CPUs.

If you use fdc, fic, or pdc, then they are broadcast to other
processors, but fdce and fice are not.

> That is the first thing I would like to check (as the first 
> signal I notice
> is a itlb miss fault and the piminfo of the 2d cpu seems to 
> show a crash
> on a branch instruction [cmpb iirc], I presume that during 
> the init of the
> second cpu this last tries to access a page which was just 
> purged by the
> first.  This is also why I would like to find the psw of this 
> second cpu
> in the mentionned pimfinfo :) )
> 
> >> But to avoid usage of cache would it be possible to access 
> global kernel's
> >> variable with absolute addressing mode? Is it feasible?
> >
> >Since the caches use virtual indices, it would make sense when using
> >physically addresses to bypass the cache. But I don't know if that's
> >really the case or not. I would expect that described in the 
> PA2.0 Arch
> >book.
> 
> I don't yet browse all the book but at a first glance ldda 
> and stda are available
> (respectively load and store doubleword absolute)...

While you can use ldda and stda to access memory using absolute
(physical) addresses instead of virtual, these instructions do *not*
bypass the cache.  And because PA processors use virtually-indexed
caches, the rules for mixing virtual and absolute accesses, and have
them all remain cache-coherent, are complicated.  If you really need to
do this, then you'll have to read and understand all of Appendix F, "TLB
and Cache Control", in the PA-RISC 2.0 Architecture manual (the "Kane"
book).

> >> btw scaning cod
> >>  related to SMP I find in smp.c a very draft of
> >> an 'ipi_init()' but unfortunately 'Ignore for now.  *May* need this
> >> "hook" to register IPI handler'..., interesting isn't it :).
> >
> >I wrote that. ipi_init and comments can be deleted.
> >I haven't see a need for ipi_init(). When I originally
> >implemented the SMP support I thought it might be.
> >
> >The IPI handler is statically "hooked" (aka registered) in
> >	arch/parisc/kernel/irq.c:cpu_irq_actions[]
> >
> >See ipi_interrupt() for IPI implementation.
> >
> Allright (clear)
> >>
> >> Is there any other platform inplementing such stuff (I try 
> to scan 2.4
> src
> >> but not found anywhere else) or some reference on to implement it?
> >
> >it == ?
> >IPI is implemented.
> 
> I continue so.
> 
> BTW here is a small 2.6 back port that may be you could co safely:
> --- processor.c.orig	2003-08-28 18:04:57.000000000 +0200
> +++ processor.c	2003-08-28 18:08:37.000000000 +0200
> @@ -370,9 +370,9 @@
>  };
>  
>  static struct parisc_driver cpu_driver = {
> -	name:		"CPU",
> -	id_table:	processor_tbl,
> -	probe:		processor_probe
> +	.name		= "CPU",
> +	.id_table	= processor_tbl,
> +	.probe		= pprocessor_probe
>  };
>  
>  /**
> 
> 
> Many thanks again for your attention,
>     Joel
> 
> 
> 
> --------------------------------------------------------------
> -----------
> Tiscali ADSL, seulement 35 eur/mois et le modem est 
> inclus...abonnez-vous!
> http://reg.tiscali.be/default.asp?lg=fr 
> 
> 
> 

Re: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Joel Soete]

[-- Attachment #1: Type: text/plain, Size: 2365 bytes --]

>
>no.
>IIRC instructions for purging the cache are broadcast to other CPUs.
>
That is the first thing I would like to check (as the first signal I notice
is a itlb miss fault and the piminfo of the 2d cpu seems to show a crash
on a branch instruction [cmpb iirc], I presume that during the init of the
second cpu this last tries to access a page which was just purged by the
first.  This is also why I would like to find the psw of this second cpu
in the mentionned pimfinfo :) )

>> But to avoid usage of cache would it be possible to access global kernel's
>> variable with absolute addressing mode? Is it feasible?
>
>Since the caches use virtual indices, it would make sense when using
>physically addresses to bypass the cache. But I don't know if that's
>really the case or not. I would expect that described in the PA2.0 Arch
>book.

I don't yet browse all the book but at a first glance ldda and stda are available
(respectively load and store doubleword absolute)...

>> btw scaning cod
>>  related to SMP I find in smp.c a very draft of
>> an 'ipi_init()' but unfortunately 'Ignore for now.  *May* need this
>> "hook" to register IPI handler'..., interesting isn't it :).
>
>I wrote that. ipi_init and comments can be deleted.
>I haven't see a need for ipi_init(). When I originally
>implemented the SMP support I thought it might be.
>
>The IPI handler is statically "hooked" (aka registered) in
>	arch/parisc/kernel/irq.c:cpu_irq_actions[]
>
>See ipi_interrupt() for IPI implementation.
>
Allright (clear)
>>
>> Is there any other platform inplementing such stuff (I try to scan 2.4
src
>> but not found anywhere else) or some reference on to implement it?
>
>it == ?
>IPI is implemented.

I continue so.

BTW here is a small 2.6 back port that may be you could co safely:
--- processor.c.orig	2003-08-28 18:04:57.000000000 +0200
+++ processor.c	2003-08-28 18:08:37.000000000 +0200
@@ -370,9 +370,9 @@
 };
 
 static struct parisc_driver cpu_driver = {
-	name:		"CPU",
-	id_table:	processor_tbl,
-	probe:		processor_probe
+	.name		= "CPU",
+	.id_table	= processor_tbl,
+	.probe		= pprocessor_probe
 };
 
 /**


Many thanks again for your attention,
    Joel



-------------------------------------------------------------------------
Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous!
http://reg.tiscali.be/default.asp?lg=fr 



[-- Attachment #2: processor.diff --]
[-- Type: application/octet-stream, Size: 335 bytes --]

--- processor.c.orig	2003-08-28 18:04:57.000000000 +0200
+++ processor.c	2003-08-28 18:08:37.000000000 +0200
@@ -370,9 +370,9 @@
 };
 
 static struct parisc_driver cpu_driver = {
-	name:		"CPU",
-	id_table:	processor_tbl,
-	probe:		processor_probe
+	.name		= "CPU",
+	.id_table	= processor_tbl,
+	.probe		= pprocessor_probe
 };
 
 /**

Re: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Grant Grundler]

On Thu, Aug 28, 2003 at 09:04:40AM +0200, Joel Soete wrote:
> Hi Grant,
> 
> >AFAIK, a cacheline will get loaded as "shared clean"
> >until someone writes to it - which is when the cacheline ping-pong
> >starts.
> 
> Mhh would it not request some kind of ipc between cpu for cache management?

no.
IIRC instructions for purging the cache are broadcast to other CPUs.

> But to avoid usage of cache would it be possible to access global kernel's
> variable with absolute addressing mode? Is it feasible?

Since the caches use virtual indices, it would make sense when using
physically addresses to bypass the cache. But I don't know if that's
really the case or not. I would expect that described in the PA2.0 Arch
book.

> btw scaning code related to SMP I find in smp.c a very draft of
> an 'ipi_init()' but unfortunately 'Ignore for now.  *May* need this
> "hook" to register IPI handler'..., interesting isn't it :).

I wrote that. ipi_init and comments can be deleted.
I haven't seen a need for ipi_init(). When I originally
implemented the SMP support I thought it might be.

The IPI handler is statically "hooked" (aka registered) in
	arch/parisc/kernel/irq.c:cpu_irq_actions[]

See ipi_interrupt() for IPI implementation.

> Is there any other platform inplementing such stuff (I try to scan 2.4 src
> but not found anywhere else) or some reference on to implement it?

it == ?
IPI is implemented.

grant

Re: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Joel Soete]

Hi Grant,

>AFAIK, a cacheline will get loaded as "shared clean"
>until someone writes to it - which is when the cacheline ping-pong
>starts.

Mhh would it not request some kind of ipc between cpu for cache management?

But to avoid usage of cache would it be possible to access global kernel's
variable with absolute addressing mode? Is it feasible?

...

btw scaning code related to SMP I find in smp.c a very draft of an 'ipi_init()'
but unfortunately 'Ignore for now. *May* need this "hook" to register IPI
handler'..., interesting isn't it :).
Is there any other platform inplementing such stuff (I try to scan 2.4 src
but not found anywhere else) or some reference on to implement it?


>PAT PDC (L-/N-class and A500) have hard coded numbers for CPUs.
>parisc-linux only uses logical CPU numbers to avoid sparsely populated
>arrays. parisc-linux can get the  "Physical CPU #" from PAT PDC.
>See code inside USE_PAT_CPUID in arch/parisc/kernel/processor.c.
>You might hack that code a bit so you can correlate logic to physical
>CPU numbers.

Ah see better now, it answers to another question.

Thanks,
    Joel




-------------------------------------------------------------------------
Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous!
http://reg.tiscali.be/default.asp?lg=fr 

Re: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Joel Soete]

>
>Now that I find what seems reasonable parameters (?) I would try to reboot
>the system tomorrow morning and relaunch test with itlb patch (just to confirm
>results).
>
Same results (definitively the test to show up this improvement, may be another
workfile?)

Joel


-------------------------------------------------------------------------
Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous!
http://reg.tiscali.be/default.asp?lg=fr 

Re: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Joel Soete]

>> 
>The additional CPUs just reference (ie load) the shared data using
>the same address. AFAIK, a cacheline will get loaded as "shared clean"
>until someone writes to it - which is when the cacheline ping-pong
>starts.

Ok I will have to re-read and again and again (each world is very important
in this book all short-cut is fatal for a good understanding)

>> Can you tell me more: in a previous piminfo collected I got for CPU#3
(3
>> is the "address" of the second cpu)

>PAT PDC (L-/N-class and A500) have hard coded numbers for CPUs.
>parisc-linux only uses logical CPU numbers to avoid sparsely populated
>arrays. parisc-linux can get the  "Physical CPU #" from PAT PDC.
>See code inside USE_PAT_CPUID in arch/parisc/kernel/processor.c.
>You might hack that code a bit so you can correlate logic to physical
>CPU numbers.

(I would do so later), I mean i would like to find the 'psw' value in a piminfo
listing (whatever the form it is: oct, hex, bin) to learn more about cpu
status at the panic moment (sorry for confusion but English is not my mother
tongue and frequently i still have pb to make understand my thought:) )

Thanks again,
    Joel
 

-------------------------------------------------------------------------
Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous!
http://reg.tiscali.be/default.asp?lg=fr 

Re: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Carlos O'Donell]

> Realistically, "logical" just means we make up a numbering scheme
> independent of what the HW tells us.  If the HW isn't telling us
> anything, then us telling the HW is fine.
> 
> The gist of the "no more logical mappings edict" is that basically we
> only have one source for CPU numbers (and it can be sparse) rather than
> two, one of which was usually compact.

I sense a Monty Python skit about '0 CPUs found' :)

HW: So how many we got today?
SW: Oh, zero.
HW: Zero?!
SW: Yeah, zaro CPU's found.
HW: Do you have an accent?
...

c.

Re: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[James Bottomley]

On Mon, 2003-08-25 at 14:19, Grant Grundler wrote:
> That's not technically possible.
> PARISC firmware uses the HPA to reference specific devices (including CPU).
> 
> We can use the same CPU number as PAT PDC and call them "physical".
> But systems which don't have PAT PDC can only use arbitrary numbers
> assigned by the parisc-linux startup code. Maybe there is a way to
> make the numbers match PIM info output but I'm not sure how.

Realistically, "logical" just means we make up a numbering scheme
independent of what the HW tells us.  If the HW isn't telling us
anything, then us telling the HW is fine.

The gist of the "no more logical mappings edict" is that basically we
only have one source for CPU numbers (and it can be sparse) rather than
two, one of which was usually compact.

James

Re: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Grant Grundler]

On Mon, Aug 25, 2003 at 11:50:45AM -0500, James Bottomley wrote:
> Not for 2.6 we shouldn't.

My intent was not to commit the code, but just get debugging working.

> The beginnings of the hotplug CPU API made
> logical CPU numbers deprecated (even for x86, which was the worst
> logical vs phsyical number abuser).  We need to move entirely to
> physical numbers only for 2.6

That's not technically possible.
PARISC firmware uses the HPA to reference specific devices (including CPU).

We can use the same CPU number as PAT PDC and call them "physical".
But systems which don't have PAT PDC can only use arbitrary numbers
assigned by the parisc-linux startup code. Maybe there is a way to
make the numbers match PIM info output but I'm not sure how.

hth,
grant

Re: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Joel Soete]

Well sorry for delay but here are some results with reaim:

** without itlb patch:
palx4000:# ./reaim -s25 -i25 -e300 -t -f workfile.new_dbase  

REAIM Workload
Times are in seconds - Child times from tms.cstime and tms.cutime

Num     Parent   Child   Child  Jobs per   Jobs/min/  Std_dev  Std_dev  JTI
Forked  Time     SysTime UTime   Minute     Child      Time     Percent 
25      169.01   53.58   110.99  914.15     36.57      4.14     2.51    
97   
50      325.85   100.05  218.86  948.29     18.97      8.06     2.54    
97   
75      490.89   155.85  326.41  944.20     12.59      15.25    3.21    
96   
100     651.37   207.02  434.83  948.77     9.49       21.20    3.37    
96   
125     812.15   259.13  542.80  951.18     7.61       24.58    3.13    
96   
150     971.88   308.85  651.77  953.82     6.36       31.30    3.33    
96   
175     1136.93  367.07  758.72  951.25     5.44       34.87    3.16    
96   
200     1295.63  416.43  867.37  953.98     4.77       41.33    3.30    
96   
225     1456.38  464.97  977.89  954.76     4.24       48.11    3.42    
96   
250     1626.22  526.17  1086.14 950.06     3.80       52.59    3.34    
96   
275     1771.56  563.64  1192.66 959.32     3.49       52.07    3.04    
96   
300     1943.16  626.54  1301.12 954.12     3.18       58.82    3.13    
96   
Max Jobs per Minute 959.32

** With itlb patch

palx4000:/usr/src/work/Bench/osdl-aim-7/src# ./reaim -s25 -i25 -e300 -t -f
workfile.new_dbase -r2                     

REAIM Workload
Times are in seconds - Child times from tms.cstime and tms.cutime

Num     Parent   Child   Child  Jobs per   Jobs/min/  Std_dev  Std_dev  JTI
Forked  Time     SysTime UTime   Minute     Child      Time     Percent 
25      169.10   54.33   110.57  913.66     36.55      4.87     2.96    
97   
50      333.73   107.53  218.98  925.90     18.52      10.96    3.40    
96   
75      496.19   160.85  326.81  934.12     12.45      14.36    2.98    
97   
100     647.24   202.66  435.30  954.82     9.55       18.62    2.97    
97   
125     811.55   258.77  543.35  951.88     7.62       27.05    3.45    
96   
150     974.62   312.28  650.87  951.14     6.34       30.33    3.21    
96   
175     1136.86  364.74  760.01  951.30     5.44       36.03    3.27    
96   
200     1305.43  426.45  865.77  946.81     4.73       41.49    3.28    
96   
225     1465.96  475.20  977.01  948.53     4.22       45.79    3.23    
96   
250     1625.77  526.57  1083.94 950.32     3.80       53.29    3.39    
96   
275     1785.44  578.00  1191.64 951.87     3.46       57.40    3.32    
96   
300     1952.36  635.80  1299.95 949.62     3.17       57.21    3.02    
96   
Max Jobs per Minute 954.82
REAIM Workload
Times are in seconds - Child times from tms.cstime and tms.cutime

Num     Parent   Child   Child  Jobs per   Jobs/min/  Std_dev  Std_dev  JTI
Forked  Time     SysTime UTime   Minute     Child      Time     Percent 
25      169.98   54.46   111.16  908.93     36.36      6.15     3.73    
96   
50      331.44   104.88  219.30  932.30     18.65      10.53    3.29    
96   
75      493.99   156.05  328.53  938.28     12.51      13.40    2.79    
97   
100     653.11   209.79  434.23  946.24     9.46       21.99    3.48    
96   
125     814.31   262.08  542.37  948.66     7.59       27.24    3.46    
96   
150     981.09   317.95  651.39  944.87     6.30       29.74    3.13    
96   
175     1137.42  364.84  760.67  950.84     5.43       36.31    3.30    
96   
200     1295.86  415.52  866.98  953.81     4.77       39.21    3.12    
96   
225     1463.61  472.96  977.13  950.05     4.22       44.79    3.16    
96   
250     1617.00  517.55  1084.14 955.47     3.82       49.42    3.15    
96   
275     1791.29  581.68  1193.78 948.76     3.45       57.33    3.31    
96   
300     1942.85  624.79  1302.10 954.27     3.18       59.52    3.16    
96   
Max Jobs per Minute 955.47

Now that I find what seems reasonable parameters (?) I would try to reboot
the system tomorrow morning and relaunch test with itlb patch (just to confirm
results).

hth,
    Joel


-------------------------------------------------------------------------
Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous!
http://reg.tiscali.be/default.asp?lg=fr 

Re: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[James Bottomley]

On Mon, 2003-08-25 at 11:45, Grant Grundler wrote:
> PAT PDC (L-/N-class and A500) have hard coded numbers for CPUs.
> parisc-linux only uses logical CPU numbers to avoid sparsely populated
> arrays. parisc-linux can get the "Physical CPU #" from PAT PDC.
> See code inside USE_PAT_CPUID in arch/parisc/kernel/processor.c.
> You might hack that code a bit so you can correlate logic to physical
> CPU numbers.

Not for 2.6 we shouldn't.  The beginnings of the hotplug CPU API made
logical CPU numbers deprecated (even for x86, which was the worst
logical vs phsyical number abuser).  We need to move entirely to
physical numbers only for 2.6

James

Re: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Grant Grundler]

On Mon, Aug 25, 2003 at 12:03:20PM +0200, Joel Soete wrote:
> So I would like to study now the early boot process
> (specialy for the second cpu) to try to understand how caches (for shared
> insn and data) are replicated into other CPU's [id]tlb.

The additional CPUs just reference (ie load) the shared data using
the same address. AFAIK, a cacheline will get loaded as "shared clean"
until someone writes to it - which is when the cacheline ping-pong
starts.

> Can you tell me more: in a previous piminfo collected I got for CPU#3 (3
> is the "address" of the second cpu)

PAT PDC (L-/N-class and A500) have hard coded numbers for CPUs.
parisc-linux only uses logical CPU numbers to avoid sparsely populated
arrays. parisc-linux can get the "Physical CPU #" from PAT PDC.
See code inside USE_PAT_CPUID in arch/parisc/kernel/processor.c.
You might hack that code a bit so you can correlate logic to physical
CPU numbers.

grant

Re: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Joel Soete]

>> btw: I countinue investigations but I still have to learn a lot about

>> how [id]tlb's cach are managed during cpu's startup...
>
>I thought this was a runtime problem (ie userspace <-> kernel
>interaction)
>
I still have to make some additional test and grab much more info.
In a previous mail (N4000 running SMP), I just report an interesting experience
(well for me, I would just like to reproduce it but now by collecting info
until crash and piminfo). After more thought, I figure out that printk()
just slow down the moment of panic. Never the less, where I am waiting a
panic (if I well understand Willy's idea), I got much 'itlb miss fault' followed
by 'dtlb miss fault'? So I would like to study now the early boot process
(specialy for the second cpu) to try to understand how caches (for shared
insn and data) are replicated into other CPU's [id]tlb.

> Ha yes, question: can I find PSW for each cpu in a piminfo?

yes

Can you tell me more: in a previous piminfo collected I got for CPU#3 (3
is the "address" of the second cpu)
[...]
-------  Processor 3 HPMC Information - PDC Version: 41.28   ------ 

Timestamp =    Mon Aug  11 12:56:02 GMT 2003    (20:03:08:11:12:56:02)

HPMC Chassis Codes 

       Chassis Code        Extension 
       ------------        --------- 
       0x0000082000ff6242  0x0000000000000000
       0x1800082011036322  0xcb81800000000000
       

General Registers 0 - 31
00-03  0000000000000000  0000000010536c70  0000000010115e58  00000000103aaf64
04-07  0000000000000002  00000000103ac494  0000000000000001  0000000010527470
08-11  0000000000000001  000000008f1f45b8  000000008f3cebc0  000000001057dcb0
12-15  00000000faf005f0  0000000000028280  0000000000020000  00000000faf00548
16-19  00000000faf005d0  0000000000004000  0000000000016000  0000000000000001
20-23  0000000000006061  000000001044ec08  0000000010539c70  000000001041b130
24-27  0000000000000000  000000000800000f  0000000010527c70  0000000010527470
28-31  0000000000000480  000000008f1f4e30  000000008f1f4e40  000000001052a470


Control Registers 0 - 31
00-03  0000000000000000  0000000000000000  0000000000000000  0000000000000000
04-07  0000000000000000  0000000000000000  0000000000000000  0000000000000000
08-11  0000000000000010  0000000000000000  00000000000000c0  0000000000000036
12-15  0000000000000000  0000000000000000  0000000000107000  ffe0000000000000
16-19  0000001f0fd05cbd  0000000000000000  0000000010116050  0000000008000240
20-23  0000000000000000  0000000000000000  000000000806070f  0000000000000000
24-27  0000000000453000  000000007f1f2000  0000000000041020  000000ffff95c810
28-31  000000ffff95c810  5555555555555555  000000008f1f4000  0000000000008020

Space Registers 0 - 7
00-03  00000400          00000400          00000000          00000400
04-07  00000000          00000000          00000000          00000000


IIA Space (back entry)       = 0x0000000000000000
IIA Offset (back entry)      = 0x0000000010116054
Check Type                   = 0x20000000
CPU State                    = 0x9e000004
Cache Check                  = 0x00000000
TLB Check                    = 0x00000000
Bus Check                    = 0x0030000d
Assists Check                = 0x00000000
Assist State                 = 0x00000000
Path Info                    = 0x00000000
System Responder Address     = 0xfffffffffed2d000
System Requestor Address     = 0x000000fffed2c000


Floating Point Registers 0 - 31
00-03  0000000000000000  0000000000000000  0000000000000000  0000000000000000
04-07  0000000010586ec0  0000000000000002  00000000104c7b68  0000000000000420
08-11  0000000000000000  0000000000000802  0000000010527470  000000001058a000
12-15  00000000135a0000  0000000000000000  000000001017dc84  00000000103ceb94
16-19  00000000000009f0  000000008facf000  0000000010527470  00000000135a0000
20-23  00000000103aa184  fffffffffffffff4  00000000003f45a2  000000000000ba2e
24-27  0000999900000000  00009999035a0b70  00000000035a0b78  000000001040d980
28-31  000000001040d980  00000000ff915e20  0000000010185248  0000000000000016


Check Summary                = 0xcb81800000000000
Available Memory             = 0x0000000100000000
CPU Diagnose Register 2      = 0x0301030800802004
CPU Status Register 0        = 0x3640c24000000000
CPU Status Register 1        = 0x8000000000000000
SADD LOG                     = 0x48e0000000000002
Read Short LOG               = 0xc18080ff80080014


-----------------  DEW 3 HPMC Information -  ------ 

Timestamp =    Mon Aug  11 12:56:02 GMT 2003    (20:03:08:11:12:56:02)

Runway Control Log Reg            = 0x0006720000000000
Runway Address Data Log Reg Odd   = 0xfffffffffffc3f00
Runway Address Data Log Reg Even  = 0xfffffffffffc3f00
Runway Address Log Reg            = 0x0000000000000048
Runway Broad Error Log Reg        = 0x00000000000000dc

  OV  RQ  RS      ESTAT      A  C  D  corr  unc  fe  cw  pf
  --  --  --      -----      -  -  -  ----  ---  --  --  --
  X             ERR_ERROR       X            X   X       

Merced Bus Requestor Address      = 0x0000000000000000
Merced Bus Target Address         = 0x0000000000000000
Merced Bus Responder Address      = 0x0000000000000000
Merced Error Status Reg           = 0x2001000000082004
Merced Error Overflow Reg         = 0x0000000000082000
Merced AERR Addr1 Log Reg         = 0x00c0000000300000
Merced AERR Addr2 Log Reg         = 0x0000000000f00000
Merced DERR  Log Reg              = 0x00c1100000000000
Merced Error Syndrome Reg         = 0x0000000052000000


-------  Processor 3  LPMC Information ------------------

[...] (all 0)


-------  Processor 3  TOC Information -------------------

[...] (all 0)

--------------  Memory Error Log Information  --------------

Bus 0 Log Information

Timestamp =    Mon Aug  11 12:56:02 GMT 2003    (20:03:08:11:12:56:02)

  OV  RQ  RS      ESTAT      A  C  D  corr  unc  fe  cw  pf
  --  --  --      -----      -  -  -  ----  ---  --  --  --
                ERR_ERROR       X                X       

Bus Requestor Address      = 0x0000000000000000
Bus Target Address         = 0x0000000000000000
Bus Responder Address      = 0x0000000000000000

Error Status Reg           = 0x0000000000080000
Error Overflow Reg         = 0x0000000000080000
AERR Address 1 Log Reg     = 0x0000000000000000
AERR Address 2 Log Reg     = 0xf800000000000000
FERR  Log Reg              = 0x0000000000000000
DERR  Log Reg              = 0x000112800051cdc0
Error Syndrome Reg         = 0x0000000000000000



 Address/Control Parity Error Registers  

   Address/Control Parity Error Bit (AE) Not Set 



Bus 1 Log Information

Timestamp =    Mon Aug  11 12:56:02 GMT 2003    (20:03:08:11:12:56:02)

  OV  RQ  RS      ESTAT      A  C  D  corr  unc  fe  cw  pf
  --  --  --      -----      -  -  -  ----  ---  --  --  --
               ERR_TIMEOUT   X               X           

Bus Requestor Address      = 0xfffffffffed2c000
Bus Target Address         = 0x00000000f000a000
Bus Responder Address      = 0x0000000000000000

Error Status Reg           = 0x0000000000000800
Error Overflow Reg         = 0x0000000000000800
AERR Address 1 Log Reg     = 0x08006000f000a000
AERR Address 2 Log Reg     = 0x6000b0002f700a10
FERR  Log Reg              = 0x0000000000000000
DERR  Log Reg              = 0x0000000000000000
Error Syndrome Reg         = 0x0000000000000000



 Address/Control Parity Error Registers  

   Address/Control Parity Error Bit (AE) Not Set 



------------  I/O Module Error Log Information  ------------

Summary of IO subsystem log entries
-----------------------------------
                        Phys Loc             Vendor  Device   Severity
Description             (hex)                 Id      Id      CORR UNC FE
 CW
-----------             -----                ------  ------   ----------------
System Bus Adapter SB  0x000000ffffffff82   0x103c  0x1050              X
System Bus Adapter SB  0x000000ffffffff82   0x103c  0x1050              X


Detail display of IO subsystem log entries
------------------------------------------

System Bus Adapter -- System Bus Interface
------------------------------------------

Timestamp =    Mon Aug  11 12:56:02 GMT 2003    (20:03:08:11:12:56:02)

  OV  RQ  RS      ESTAT      A  C  D  corr  unc  fe  cw  pf
  --  --  --      -----      -  -  -  ----  ---  --  --  --
  X       X     ERR_ERROR       X                X       

IO Requestor Address    = 0x0000000000000000
IO Target Address       = 0x0000000000000000
IO Responder Address    = 0xfffffffffed00000
IO Physical Location    = 0x000000ffffffff82
IO Hardware Path        = 0x00ffffffffffff00

Module Error Register   = 0x0000000007ff0034

System Bus Adapter -- System Bus Interface
------------------------------------------

Timestamp =    Mon Aug  11 12:56:02 GMT 2003    (20:03:08:11:12:56:02)

  OV  RQ  RS      ESTAT      A  C  D  corr  unc  fe  cw  pf
  --  --  --      -----      -  -  -  ----  ---  --  --  --
  X       X     ERR_ERROR       X                X       

IO Requestor Address    = 0x0000000000000000
IO Target Address       = 0x0000000000000000
IO Responder Address    = 0xfffffffffed40000
IO Physical Location    = 0x000000ffffffff82
IO Hardware Path        = 0x00ffffffffffff01

Module Error Register   = 0x0000000007ff0034

[...]

Under which field name is it hiden?

Thanks again,
    Joel



btw: a preliminary pim analyse of above mentioned piminfo reports me:
[...]
Parse IAOQ = 0x000000001010b8cc for CPU[1]

Func: update_mmu_cache, Off: 0x4, Addr: 0x1010b8cc

    1010b8c0:	37 de 3f 01 	ldo -80(sp),sp
    1010b8c4:	00 00 00 00 	break 0,0
	...
000000001010b8c8 <update_mmu_cache>:

	...
    1010b8c8:	0f c2 12 c1 	std rp,-10(,sp)
    1010b8cc:	2b 6a 20 00 	addil 15000,dp,%r1
[...]

hmm very interesting (A yes I was much trying to debug my script then actualy
reading outputs: my bad :( )

[...]
Parse IAOQ = 0x0000000010116054 for CPU[3]

Func: smp_call_function, Off: 0x274, Addr: 0x10116054

    10116050:	08 00 02 40 	nop
    10116054:	0e a0 10 d3 	ldd 0(,r21),r19
    10116058:	0a 93 04 33 	sub r19,r20,r19
    1011605c:	ee 60 ff c5 	cmpib,*> 0,r19,10116044 <smp_call_function+0x264>



-------------------------------------------------------------------------
Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous!
http://reg.tiscali.be/default.asp?lg=fr 

Re: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Grant Grundler]

On Sun, Aug 24, 2003 at 12:51:10PM +0000, Joel Soete wrote:
> btw: I countinue investigations but I still have to learn a lot about 
> how [id]tlb's cach are managed during cpu's startup...

I thought this was a runtime problem (ie userspace <-> kernel
interaction)

> Ha yes, question: can I find PSW for each cpu in a piminfo?

yes


grant

Re: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Joel Soete]

Grant Grundler wrote:

> [...] at least until the VM

> address aliasing is fixed and you can run 8-way on the N-class.

:)) it was just a machine for testing and so to save money there was 
just purchased 2 cpu (but for my part it would already be nice to make 
it run in SMP mode :) )

btw: I countinue investigations but I still have to learn a lot about 
how [id]tlb's cach are managed during cpu's startup...

Ha yes, question: can I find PSW for each cpu in a piminfo?

Thanks again,
Joel

Re: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Grant Grundler]

On Sat, Aug 23, 2003 at 04:54:26PM +0100, Joel Soete wrote:
> With the patch kernel I also want to launch 3 run test but with -e300 (Just
> have a N obviously UP 550Mhz?).

Pick whatever parameters are reasonable.
The -e100 to -e500 worked well on a dual 1Ghz rx2600 with 3 or 4 GB of RAM.
You might try -e50 -> -e250 in steps of 50....at least until the VM
address aliasing is fixed and you can run 8-way on the N-class.

> The first two run seems to work fine when during the last run I get a lot
> of messages "Child caught raw signal ?" and so I could not grab (cut and
> past) the first results :( .
> 
> I now relaunch test for only two runs and so hope the results for next week,
> sorry.

np - thanks.

grant

RE: [parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Joel Soete]

>Congratulation, I will try it also on the N (64bits)

I grab last osdl-aim-7-0.1.9 (date Aug 04) and launch the test that Grant
mentionned (I just stop the 3d run (option -r3) with kernel without patch
because -e500 seems to take too much time: full night and I want to test

the patched kernel)

With the patch kernel I also want to launch 3 run test but with -e300 (Just
have a N obviously UP 550Mhz?).
The first two run seems to work fine when during the last run I get a lot
of messages "Child caught raw signal ?" and so I could not grab (cut and
past) the first results :( .

I now relaunch test for only two runs and so hope the results for next week,
sorry.

Thanks again,
    Joel


------------------------------------------
------------------------------
Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous!
http://reg.tiscali.be/default.asp?lg=
> r


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.p
risc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux





-------------------------------------------------------------------------
Tiscali ADSL, seulement 35 eur/mois et le modem est inclus...abonnez-vous!
http://reg.tiscali.be/default.asp?lg=fr 

[parisc-linux] Re: [parisc-linux-cvs] linux carlos

[Carlos O'Donell]

[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]

> CVSROOT:	/var/cvs
> Module name:	linux
> Changes by:	carlos	02/11/03 17:46:26
> 
> Modified files:
> 	arch/parisc/kernel: traps.c 
> 
> Log message:
> Add support for Trap 13 (Conditionals). Fix Trap 16/17 so they don't hose the processor. Cosmetic changes and the addition of a few comments.
> 

This code has been sitting in my tree since Krystof managed to figure
out a really cool way to hang my C3K and A500. It looks like FIC'ing
into an unmapped page will cause a Trap 17, which should really signal
the process and not gutter the processor in parisc_termiante.

I also added a somewhat shakey implementation of Trap 13, based on a
reverse engineering of old code that was meant for HP/UX.

Initially Grant and myself took the code to Frank Rowand, who admitted
that his PARISC knowledge was too out of date to validate the patch.

Jsm, I know you're busy, so I've just put the code into CVS, even if
it's wrong it's a closer step towards correctness :) It also stops
regular users from hosing the box.

c.



[-- Attachment #2: traps.diff --]
[-- Type: text/plain, Size: 4039 bytes --]

Index: traps.c
===================================================================
RCS file: /var/cvs/linux/arch/parisc/kernel/traps.c,v
retrieving revision 1.66
diff -u -p -r1.66 traps.c
--- traps.c	21 Oct 2002 15:31:56 -0000	1.66
+++ traps.c	4 Nov 2002 00:38:59 -0000
@@ -426,7 +426,7 @@ void transfer_pim_to_trap_frame(struct p
 
 
 /*
- * This routine handles page faults.  It determines the address,
+ * This routine handles various exception codes.  It determines the address,
  * and the problem, and then passes it off to one of the appropriate
  * routines.
  */
@@ -445,8 +445,18 @@ void parisc_terminate(char *msg, struct 
 	if (!console_drivers)
 		pdc_console_restart();
 
-	if (code == 1)
-	    transfer_pim_to_trap_frame(regs);
+
+	/* Not all switch paths will gutter the processor... */
+	switch(code){
+
+	case 1:
+		transfer_pim_to_trap_frame(regs);
+		break;
+	    
+	default:
+		/* Fall through */
+		break;
+	}
 
 	show_stack(regs);
 
@@ -462,6 +472,7 @@ void parisc_terminate(char *msg, struct 
 	 * system will shut down immediately right here. */
 	pdc_soft_power_button(0);
 	
+	/* Gutter the processor... */
 	for(;;)
 	    ;
 }
@@ -562,6 +573,7 @@ void handle_interruption(int code, struc
 
 		die_if_kernel("Privileged register usage", regs, code);
 		si.si_code = ILL_PRVREG;
+		/* Fall thru */
 	give_sigill:
 		si.si_signo = SIGILL;
 		si.si_errno = 0;
@@ -576,6 +588,17 @@ void handle_interruption(int code, struc
 		si.si_addr = (void *) regs->iaoq[0];
 		force_sig_info(SIGFPE, &si, current);
 		return;
+	
+	case 13:
+		/* Conditional Trap 
+		   The condition succees in an instruction which traps on condition  */
+		si.si_signo = SIGFPE;
+		/* Set to zero, and let the userspace app figure it out from
+		   the insn pointed to by si_addr */
+		si.si_code = 0;
+		si.si_addr = (void *) regs->iaoq[0];
+		force_sig_info(SIGFPE, &si, current);
+		return;
 
 	case 14:
 		/* Assist Exception Trap, i.e. floating point exception. */
@@ -583,14 +606,22 @@ void handle_interruption(int code, struc
 		handle_fpe(regs);
 		return;
 
+	case 15: 
+		/* Data TLB miss fault/Data page fault */	
+		/* Fall thru */
+	case 16:
+		/* Non-access instruction TLB miss fault */
+		/* The instruction TLB entry needed for the target address of the FIC
+		   is absent, and hardware can't find it, so we get to cleanup */
+		/* Fall thru */
 	case 17:
 		/* Non-access data TLB miss fault/Non-access data page fault */
 		/* TODO: Still need to add slow path emulation code here */
-		
-		pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
-
+		/* TODO: Understand what is meant by the TODO listed 
+		   above this one. (Carlos) */
 		fault_address = regs->ior;
-		parisc_terminate("Non access data tlb fault!",regs,code,fault_address);
+		fault_space = regs->isr;
+		break;
 
 	case 18:
 		/* PCXS only -- later cpu's split this into types 26,27 & 28 */
@@ -600,9 +631,8 @@ void handle_interruption(int code, struc
 			return;
 		}
 		/* Fall Through */
-
-	case 15: /* Data TLB miss fault/Data page fault */
-	case 26: /* PCXL: Data memory access rights trap */
+	case 26: 
+		/* PCXL: Data memory access rights trap */
 		fault_address = regs->ior;
 		fault_space   = regs->isr;
 		break;
@@ -632,6 +662,11 @@ void handle_interruption(int code, struc
 		pt_regs_to_ssp(regs, &ssp);
 		kgdb_trap(I_TAKEN_BR, &ssp, 1);
 		ssp_to_pt_regs(&ssp, regs);
+
+		/* FIXME: Should this break without setting fault_address
+		   and fault_space? They are required for the dump later on.
+		   (Carlos) */
+		
 		break;
 #endif /* CONFIG_KWDB */
 
@@ -667,7 +702,6 @@ void handle_interruption(int code, struc
 			up_read(&current->mm->mmap_sem);
 		}
 		/* Fall Through */
-
 	case 27: 
 		/* Data memory protection ID trap */
 		die_if_kernel("Protection id trap", regs, code);
@@ -734,8 +768,8 @@ void handle_interruption(int code, struc
 
 	    if (fault_space == 0) {
 		pdc_chassis_send_status(PDC_CHASSIS_DIRECT_PANIC);
-
 		parisc_terminate("Kernel Fault", regs, code, fault_address);
+		/** NOT REACHED **/
 	    }
 	}