Linux MIPS Architecture development
 help / color / mirror / Atom feed
* another 4kc machine check.
@ 2005-04-07 14:06 Greg Weeks
  2005-04-08 14:45 ` Greg Weeks
  0 siblings, 1 reply; 16+ messages in thread
From: Greg Weeks @ 2005-04-07 14:06 UTC (permalink / raw)
  To: linux-mips

This is the malta branch with the tlb patch from Ralf applied. The LTP test:


-bash-2.05b# shmem_test_06
shmem_test_06: IPC Shared Memory TestSuite program
 
        mykey to uniquely identify the shared memory segment 0x330b035a
 
...
       
        Detach from the segment using the shmdt subroutine
 
        Release shared memory
 

causes:

timesys-bsp login: Got mcheck at 802199bc
Cpu 0
$ 0   : 00000000 1000fc00 00000004 00000000
$ 4   : 80401d30 00020004 c0002034 803e5964
$ 8   : 803e598c 00000000 fffffffa 8299f470
$12   : 00000001 000000ff 00000000 00000000
$16   : 80400000 00020004 82d15720 82d15724
$20   : 60100000 803e5964 8337dd38 00000000
$24   : 00000000 8014e6a4
$28   : 82d3e000 82d3fe38 10021a80 8021d314
Hi    : d3c9c18f
Lo    : 7263fc03
epc   : 802199bc ipc_lock+0x14/0x54     Not tainted
ra    : 8021d314 shm_close+0x5c/0x11c
Status: 1020fc03    KERNEL EXL IE
Cause : 00800060
PrId  : 00018001
                
Kernel panic - not syncing: Caught Machine Check exception - caused by 
multiple matching entries in the TLB.
                            
To run this test I have a different config from the default malta.
[gweeks@tanith linux]$ diff -du arch/mips/configs/malta_defconfig .config
--- arch/mips/configs/malta_defconfig   2005-03-18 12:36:52.000000000 -0500
+++ .config     2005-04-07 09:42:47.000000000 -0400
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
 # Linux kernel version: 2.6.12-rc1
-# Fri Mar 18 15:41:40 2005
+# Thu Apr  7 09:42:47 2005
 #
 CONFIG_MIPS=y
 
@@ -18,7 +18,7 @@
 CONFIG_LOCALVERSION=""
 CONFIG_SWAP=y
 CONFIG_SYSVIPC=y
-# CONFIG_POSIX_MQUEUE is not set
+CONFIG_POSIX_MQUEUE=y
 # CONFIG_BSD_PROCESS_ACCT is not set
 CONFIG_SYSCTL=y
 # CONFIG_AUDIT is not set
@@ -158,6 +158,7 @@
 # CONFIG_PAGE_SIZE_16KB is not set
 # CONFIG_PAGE_SIZE_64KB is not set
 CONFIG_CPU_HAS_PREFETCH=y
+CONFIG_BOARD_HAS_MEMCPY_PREFETCH_BUG=y
 # CONFIG_64BIT_PHYS_ADDR is not set
 # CONFIG_CPU_ADVANCED is not set
 CONFIG_CPU_HAS_LLSC=y
@@ -187,7 +188,7 @@
 # Executable file formats
 #
 CONFIG_BINFMT_ELF=y
-# CONFIG_BINFMT_MISC is not set
+CONFIG_BINFMT_MISC=y
 CONFIG_TRAD_SIGNALS=y
 
 #
@@ -394,8 +395,7 @@
 CONFIG_DM_SNAPSHOT=m
 CONFIG_DM_MIRROR=m
 CONFIG_DM_ZERO=m
-CONFIG_DM_MULTIPATH=m
-CONFIG_DM_MULTIPATH_EMC=m
+# CONFIG_DM_MULTIPATH is not set
 
 #
 # Fusion MPT device support
@@ -663,7 +663,7 @@
 CONFIG_NET_QOS=y
 CONFIG_NET_ESTIMATOR=y
 CONFIG_NET_CLS=y
-CONFIG_NET_CLS_BASIC=m
+# CONFIG_NET_CLS_BASIC is not set
 CONFIG_NET_CLS_TCINDEX=m
 CONFIG_NET_CLS_ROUTE4=m
 CONFIG_NET_CLS_ROUTE=y
@@ -1006,10 +1006,13 @@
 CONFIG_PROC_FS=y
 CONFIG_PROC_KCORE=y
 CONFIG_SYSFS=y
-# CONFIG_DEVFS_FS is not set
+CONFIG_DEVFS_FS=y
+# CONFIG_DEVFS_MOUNT is not set
+# CONFIG_DEVFS_DEBUG is not set
 CONFIG_DEVPTS_FS_XATTR=y
 CONFIG_DEVPTS_FS_SECURITY=y
-# CONFIG_TMPFS is not set
+CONFIG_TMPFS=y
+# CONFIG_TMPFS_XATTR is not set
 # CONFIG_HUGETLB_PAGE is not set
 CONFIG_RAMFS=y
 
@@ -1138,7 +1141,7 @@
 CONFIG_CRYPTO_SHA256=m
 CONFIG_CRYPTO_SHA512=m
 CONFIG_CRYPTO_WP512=m
-CONFIG_CRYPTO_TGR192=m
+# CONFIG_CRYPTO_TGR192 is not set
 CONFIG_CRYPTO_DES=m
 CONFIG_CRYPTO_BLOWFISH=m
 CONFIG_CRYPTO_TWOFISH=m
[gweeks@tanith linux]$

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: another 4kc machine check.
  2005-04-07 14:06 another 4kc machine check Greg Weeks
@ 2005-04-08 14:45 ` Greg Weeks
  2005-04-08 16:13   ` Ralf Baechle
  0 siblings, 1 reply; 16+ messages in thread
From: Greg Weeks @ 2005-04-08 14:45 UTC (permalink / raw)
  To: linux-mips

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

Greg Weeks wrote:

> This is the malta branch with the tlb patch from Ralf applied. The LTP 
> test:
>
>
> -bash-2.05b# shmem_test_06

This test does some mucking with shmat at fixed addresses that might not 
be correct for mips. I still wouldn't expect to see a machine check when 
it goes to free the shared memory areas. I'm going to try it on a 24K 
malta as soon as I get yamon on it and can get it booted.

Greg Weeks


[-- Attachment #2: shmem_test_06.c --]
[-- Type: text/x-c, Size: 12262 bytes --]

/*
 *
 *   Copyright (c) International Business Machines  Corp., 2001
 *
 *   This program is free software;  you can redistribute it and/or modify
 *   it under the terms of the GNU General Public License as published by
 *   the Free Software Foundation; either version 2 of the License, or
 *   (at your option) any later version.
 *
 *   This program is distributed in the hope that it will be useful,
 *   but WITHOUT ANY WARRANTY;  without even the implied warranty of
 *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See
 *   the GNU General Public License for more details.
 *
 *   You should have received a copy of the GNU General Public License
 *   along with this program;  if not, write to the Free Software
 *   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 */

/*
 * Copyright (C) Bull S.A. 1996
 * Level 1,5 Years Bull Confidential and Proprietary Information
 */

/*---------------------------------------------------------------------+
|                           shmem_test_06.c                            |
| ==================================================================== |
| Title:        Segment Register 0xE                                   |
|                                                                      |
| Purpose:      simultaneous attachment of more than ten shared        |
|               memory regions to a process. Using segment registers   |
|               0x3 to 0xC and 0xE .                                   |
|                                                                      |
| Description:  Simplistic test to verify that a process can obtain    |
|               11 shared memory regions in the adress space from      |
|               0x30000000 to 0xCFFFFFFF and 0xE0000000 to 0xEFFFFFFF. |
|                                                                      |
|                                                                      |
| Algorithm:    *  from 1 up to 11                                     |
|               {                                                      |
|               o  Create a key to uniquely identify the shared segment|
|		   using ftok()	subroutine.			       |
|               o  Obtain a unique shared memory identifier with       |
|                  shmget ()                                           |
|               o  Map the shared memory segment to the current        |
|                  process with shmat ()                               |
|               o  Index through the shared memory segment             |
|               }                                                      |
|               *  from 1 up to 11                                     |
|               {                                                      |
|               o  Detach from the segment with shmdt()                |
|               o  Release the shared memory segment with shmctl ()    |
|               }                                                      |
|                                                                      |
| System calls: The following system calls are tested:                 |
|                                                                      |
|               ftok()                                                 |
|               shmget ()                                              |
|               shmat ()                                               |
|               shmdt ()                                               |
|               shmctl ()                                              |
|                                                                      |
| Usage:        shmem_test_06                                          |
|                                                                      |
| To compile:   cc -O -g  shmem_test_06.c -o shmem_test_06 -lbsd       |
|                                                                      |
| Last update:                                                         |
|                                                                      |
| Change Activity                                                      |
|                                                                      |
|   Version  Date    Name  Reason                                      |
|    0.1     010797  J.Malcles  initial version for 4.2.G              |
|                                                                      |
|                                                                      |
+---------------------------------------------------------------------*/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <sys/shm.h>

#include <sys/types.h>
#include <sys/ipc.h>

#include <sys/stat.h>
/*
off_t offsets[] = {
0x20000000,
0x30000000,
0x48000000,
0x50000000,
0x60000000,
0x70000000,
0x80000000,
0x90000000,
0xA0000000,
0xB0000000,
0xBFE00000,
};
*/
off_t offsets[] = {
0x20000000,
0x00000000,
0x48000000,
0x50000000,
0x60000000,
0x60200000,
0x60400000,
0x70200000,
0x70400000,
0x70600000,
0x70800000,
};
int offsets_cnt = sizeof (offsets) /sizeof (offsets[0]);
/* Defines
 *
 * MAX_SHMEM_SIZE: maximum shared memory segment size of 256MB 
 *
 * MAX_SHMEM_NUMBER: maximum number of simultaneous attached shared memory 
 * regions
 *
 * DEFAULT_SHMEM_SIZE: default shared memory size, unless specified with
 * -s command line option
 * 
 * SHMEM_MODE: shared memory access permissions (permit process to read
 * and write access)
 * 
 * USAGE: usage statement
 */
#define MAX_SHMEM_SIZE		256*1024*1024
#define MAX_SHMEM_NUMBER	11
#define DEFAULT_SHMEM_SIZE	1024*1024
#define	SHMEM_MODE		(SHM_R | SHM_W)
#define USAGE	"\nUsage: %s [-s shmem_size]\n\n" \
		"\t-s shmem_size  size of shared memory segment (bytes)\n" \
		"\t               (must be less than 256MB!)\n\n"

#define GOTHERE printf("got to line %d\n", __LINE__);

/*
 * Function prototypes
 *
 * parse_args (): Parse command line arguments
 * sys_error (): System error message function
 * error (): Error message function
 */
void parse_args (int, char **);
void sys_error (const char *, int);
void error (const char *, int);

/*
 * Global variables
 * 
 * shmem_size: shared memory segment size (in bytes)
 */
int shmem_size = DEFAULT_SHMEM_SIZE;


/*---------------------------------------------------------------------+
|                               main                                   |
| ==================================================================== |
|                                                                      |
|                                                                      |
| Function:  Main program  (see prolog for more details)               |
|                                                                      |
| Returns:   (0)  Successful completion                                |
|            (-1) Error occurred                                       |
|                                                                      |
+---------------------------------------------------------------------*/
int main (int argc, char **argv)
{
  off_t offset;
  int i;
  
  int shmid[MAX_SHMEM_NUMBER];	/* (Unique) Shared memory identifier */
  
  char *shmptr[MAX_SHMEM_NUMBER];	/* Shared memory segment address */
  char	*ptr;		/* Index into shared memory segment */
  
  int value = 0;	/* Value written into shared memory segment */
  
  key_t mykey[MAX_SHMEM_NUMBER];
  char * null_file = "/dev/null";
  char  proj[MAX_SHMEM_NUMBER] = {
    '3', '4', '5', '6', '7', '8', '9', 'A', 'B', 'C', 'E'
  };
  
  
  /*
   * Parse command line arguments and print out program header
   */
  parse_args (argc, argv);
  printf ("%s: IPC Shared Memory TestSuite program\n", *argv);
  
  for (i=0; i<offsets_cnt; i++) 
    {
      char tmpstr[256];
      /*
       * Create a key to uniquely identify the shared segment
       */
      
      mykey[i] = ftok(null_file,proj[i]);
      
      printf ("\n\tmykey to uniquely identify the shared memory segment 0x%x\n",mykey[i]);
      
      printf ("\n\tGet shared memory segment (%d bytes)\n", shmem_size);
      /*
       * Obtain a unique shared memory identifier with shmget ().
       */
      
      if ((long)(shmid[i]= shmget (mykey[i], shmem_size, IPC_CREAT | 0666 )) < 0)
	sys_error ("shmget failed", __LINE__);
      
      
      printf ("\n\tAttach shared memory segment to process\n");
      /*
       * Attach the shared memory segment to the process
       */
      offset = offsets[i];

      if ((long)(shmptr[i] = (char *) shmat (shmid[i], (const void*)offset, 0)) == -1)
	{
	  sprintf(tmpstr, "shmat failed - return: %p", shmptr[i]);
	  sys_error (tmpstr, __LINE__);
	}

      
      printf ("\n\tShared memory segment address : 0x%p \n",shmptr[i]);
      
      printf ("\n\tIndex through shared memory segment ...\n");
      
      /*
       * Index through the shared memory segment
       */
      
      for (ptr=shmptr[i]; ptr < (shmptr[i] + shmem_size); ptr++)
	*ptr = value++;
      
    } // for 1..11

  printf ("\n\tDetach from the segment using the shmdt subroutine\n");
  
  printf ("\n\tRelease shared memory\n");
  
  for (i=0; i<offsets_cnt; i++) 
    {
      // Detach from the segment
      
      shmdt( shmptr[i] );
      
      // Release shared memory
      
      if (shmctl (shmid[i], IPC_RMID, 0) < 0)
	sys_error ("shmctl failed", __LINE__);
      
    } // 2nd for 1..11
  /* 
   * Program completed successfully -- exit
   */
  
  printf ("\nsuccessful!\n");
  
  return (0);
  
}


/*---------------------------------------------------------------------+
|                             parse_args ()                            |
| ==================================================================== |
|                                                                      |
| Function:  Parse the command line arguments & initialize global      |
|            variables.                                                |
|                                                                      |
| Updates:   (command line options)                                    |
|                                                                      |
|            [-s] size: shared memory segment size                     |
|                                                                      |
+---------------------------------------------------------------------*/
void parse_args (int argc, char **argv)
{
  int	i;
  int	errflag = 0;
  char	*program_name = *argv;
  extern char 	*optarg;	/* Command line option */
  
  while ((i = getopt(argc, argv, "s:?")) != EOF) {
    switch (i) {
    case 's':
      shmem_size = atoi (optarg);
      break;
    case '?':
      errflag++;
      break;
    }
  }
  
  if (shmem_size < 1 || shmem_size > MAX_SHMEM_SIZE)
    errflag++;
  
  if (errflag) {
    fprintf (stderr, USAGE, program_name);
    exit (2);
  }
}


/*---------------------------------------------------------------------+
  |                             sys_error ()                             |
  | ==================================================================== |
  |                                                                      |
  | Function:  Creates system error message and calls error ()           |
  |                                                                      |
  +---------------------------------------------------------------------*/
void sys_error (const char *msg, int line)
{
  char syserr_msg [256];
  
  sprintf (syserr_msg, "%s: %s\n", msg, strerror (errno));
  error (syserr_msg, line);
}


/*---------------------------------------------------------------------+
|                               error ()                               |
| ==================================================================== |
|                                                                      |
| Function:  Prints out message and exits...                           |
|                                                                      |
+---------------------------------------------------------------------*/
void error (const char *msg, int line)
{
  fprintf (stderr, "ERROR [line: %d] %s\n", line, msg);
  exit (-1);
}

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: another 4kc machine check.
  2005-04-08 14:45 ` Greg Weeks
@ 2005-04-08 16:13   ` Ralf Baechle
  2005-04-08 16:45     ` Greg Weeks
  0 siblings, 1 reply; 16+ messages in thread
From: Ralf Baechle @ 2005-04-08 16:13 UTC (permalink / raw)
  To: Greg Weeks; +Cc: linux-mips

On Fri, Apr 08, 2005 at 10:45:48AM -0400, Greg Weeks wrote:

> >This is the malta branch with the tlb patch from Ralf applied. The LTP 
> >test:

Credits for this patch go to Maciej who actually went through the pain
of debugging this problem that did show it's ugly head long, long after
the affected revision has been obsoleted by newer revisions.

> >-bash-2.05b# shmem_test_06
> 
> This test does some mucking with shmat at fixed addresses that might not 
> be correct for mips. I still wouldn't expect to see a machine check when 
> it goes to free the shared memory areas. I'm going to try it on a 24K 
> malta as soon as I get yamon on it and can get it booted.

I've been able to reproduce it on on two 4Kc boards of different revisions
so this seems to be something else.  It does not hit 5Kc and 24K.

  Ralf

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: another 4kc machine check.
  2005-04-08 16:13   ` Ralf Baechle
@ 2005-04-08 16:45     ` Greg Weeks
  2005-04-11 19:47       ` Greg Weeks
  0 siblings, 1 reply; 16+ messages in thread
From: Greg Weeks @ 2005-04-08 16:45 UTC (permalink / raw)
  To: Ralf Baechle; +Cc: linux-mips

Ralf Baechle wrote:

>On Fri, Apr 08, 2005 at 10:45:48AM -0400, Greg Weeks wrote:
>
>  
>
>>>This is the malta branch with the tlb patch from Ralf applied. The LTP 
>>>test:
>>>      
>>>
>
>Credits for this patch go to Maciej who actually went through the pain
>of debugging this problem that did show it's ugly head long, long after
>the affected revision has been obsoleted by newer revisions.
>
>  
>
>>>-bash-2.05b# shmem_test_06
>>>      
>>>
>>This test does some mucking with shmat at fixed addresses that might not 
>>be correct for mips. I still wouldn't expect to see a machine check when 
>>it goes to free the shared memory areas. I'm going to try it on a 24K 
>>malta as soon as I get yamon on it and can get it booted.
>>    
>>
>
>I've been able to reproduce it on on two 4Kc boards of different revisions
>so this seems to be something else.  It does not hit 5Kc and 24K.
>  
>
Have you tried a 4kec? That's the only other mips board I have available.

Greg Weeks

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: another 4kc machine check.
  2005-04-08 16:45     ` Greg Weeks
@ 2005-04-11 19:47       ` Greg Weeks
  2005-04-11 20:27         ` Kevin D. Kissell
                           ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Greg Weeks @ 2005-04-11 19:47 UTC (permalink / raw)
  To: Ralf Baechle; +Cc: linux-mips

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

This patch appears to fix my machine check problem on the 4kc. The 4kc 
shouldn't need an ssnop here, but this appears to fix it.

Greg Weeks

[-- Attachment #2: mips.4kc.tlb.patch --]
[-- Type: text/x-patch, Size: 331 bytes --]

--- mips-malta4kcle-basic/arch/mips/mm/tlbex.c-orig
+++ mips-malta4kcle-basic/arch/mips/mm/tlbex.c
@@ -847,7 +847,6 @@
 
 	case CPU_R10000:
 	case CPU_R12000:
-	case CPU_4KC:
 	case CPU_SB1:
 	case CPU_4KSC:
 	case CPU_20KC:
@@ -874,6 +873,7 @@
 		tlbw(p);
 		break;
 
+	case CPU_4KC:
 	case CPU_4KEC:
 	case CPU_24K:
 		i_ehb(p);

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: another 4kc machine check.
  2005-04-11 19:47       ` Greg Weeks
@ 2005-04-11 20:27         ` Kevin D. Kissell
  2005-04-11 20:27           ` Kevin D. Kissell
                             ` (2 more replies)
  2005-04-11 20:42         ` Kevin D. Kissell
  2005-06-10 16:39         ` Chris Wedgwood
  2 siblings, 3 replies; 16+ messages in thread
From: Kevin D. Kissell @ 2005-04-11 20:27 UTC (permalink / raw)
  To: Greg Weeks, Ralf Baechle; +Cc: linux-mips

If the 4KC and 4KEC need it, so does the 4KSC (and 4KSD).

----- Original Message ----- 
From: "Greg Weeks" <greg.weeks@timesys.com>
To: "Ralf Baechle" <ralf@linux-mips.org>
Cc: <linux-mips@linux-mips.org>
Sent: Monday, April 11, 2005 21:47
Subject: Re: another 4kc machine check.


> This patch appears to fix my machine check problem on the 4kc. The 4kc 
> shouldn't need an ssnop here, but this appears to fix it.
> 
> Greg Weeks
> 


--------------------------------------------------------------------------------


> --- mips-malta4kcle-basic/arch/mips/mm/tlbex.c-orig
> +++ mips-malta4kcle-basic/arch/mips/mm/tlbex.c
> @@ -847,7 +847,6 @@
>  
>   case CPU_R10000:
>   case CPU_R12000:
> - case CPU_4KC:
>   case CPU_SB1:
>   case CPU_4KSC:
>   case CPU_20KC:
> @@ -874,6 +873,7 @@
>   tlbw(p);
>   break;
>  
> + case CPU_4KC:
>   case CPU_4KEC:
>   case CPU_24K:
>   i_ehb(p);
> 

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: another 4kc machine check.
  2005-04-11 20:27         ` Kevin D. Kissell
@ 2005-04-11 20:27           ` Kevin D. Kissell
  2005-04-12 14:52           ` Greg Weeks
  2005-04-12 15:22           ` Maciej W. Rozycki
  2 siblings, 0 replies; 16+ messages in thread
From: Kevin D. Kissell @ 2005-04-11 20:27 UTC (permalink / raw)
  To: Greg Weeks, Ralf Baechle; +Cc: linux-mips

If the 4KC and 4KEC need it, so does the 4KSC (and 4KSD).

----- Original Message ----- 
From: "Greg Weeks" <greg.weeks@timesys.com>
To: "Ralf Baechle" <ralf@linux-mips.org>
Cc: <linux-mips@linux-mips.org>
Sent: Monday, April 11, 2005 21:47
Subject: Re: another 4kc machine check.


> This patch appears to fix my machine check problem on the 4kc. The 4kc 
> shouldn't need an ssnop here, but this appears to fix it.
> 
> Greg Weeks
> 


--------------------------------------------------------------------------------


> --- mips-malta4kcle-basic/arch/mips/mm/tlbex.c-orig
> +++ mips-malta4kcle-basic/arch/mips/mm/tlbex.c
> @@ -847,7 +847,6 @@
>  
>   case CPU_R10000:
>   case CPU_R12000:
> - case CPU_4KC:
>   case CPU_SB1:
>   case CPU_4KSC:
>   case CPU_20KC:
> @@ -874,6 +873,7 @@
>   tlbw(p);
>   break;
>  
> + case CPU_4KC:
>   case CPU_4KEC:
>   case CPU_24K:
>   i_ehb(p);
> 

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: another 4kc machine check.
  2005-04-11 19:47       ` Greg Weeks
  2005-04-11 20:27         ` Kevin D. Kissell
@ 2005-04-11 20:42         ` Kevin D. Kissell
  2005-04-11 20:42           ` Kevin D. Kissell
  2005-06-10 16:39         ` Chris Wedgwood
  2 siblings, 1 reply; 16+ messages in thread
From: Kevin D. Kissell @ 2005-04-11 20:42 UTC (permalink / raw)
  To: Greg Weeks, Ralf Baechle; +Cc: linux-mips

One further comment:


> This patch appears to fix my machine check problem on the 4kc. The 4kc 
> shouldn't need an ssnop here, but this appears to fix it.


The 4Kc shouldn't need an ssnop/ehb for the purposes of a *load*, but
if the exception was on an instruction fetch, the documentation is reasonably
clear that there's a hazard of 3 cycles before the new entry can be used for
a fetch - which is what ERET will do in the case of a instruction fetch miss.

            Regards,

            Kevin K.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: another 4kc machine check.
  2005-04-11 20:42         ` Kevin D. Kissell
@ 2005-04-11 20:42           ` Kevin D. Kissell
  0 siblings, 0 replies; 16+ messages in thread
From: Kevin D. Kissell @ 2005-04-11 20:42 UTC (permalink / raw)
  To: Greg Weeks, Ralf Baechle; +Cc: linux-mips

One further comment:


> This patch appears to fix my machine check problem on the 4kc. The 4kc 
> shouldn't need an ssnop here, but this appears to fix it.


The 4Kc shouldn't need an ssnop/ehb for the purposes of a *load*, but
if the exception was on an instruction fetch, the documentation is reasonably
clear that there's a hazard of 3 cycles before the new entry can be used for
a fetch - which is what ERET will do in the case of a instruction fetch miss.

            Regards,

            Kevin K.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: another 4kc machine check.
  2005-04-11 20:27         ` Kevin D. Kissell
  2005-04-11 20:27           ` Kevin D. Kissell
@ 2005-04-12 14:52           ` Greg Weeks
  2005-04-12 15:22           ` Maciej W. Rozycki
  2 siblings, 0 replies; 16+ messages in thread
From: Greg Weeks @ 2005-04-12 14:52 UTC (permalink / raw)
  To: Kevin D. Kissell; +Cc: Ralf Baechle, linux-mips

Kevin D. Kissell wrote:

>If the 4KC and 4KEC need it, so does the 4KSC (and 4KSD).
>
>  
>
Is this a reasonable thing to do though. I always hate making changes 
that work, but that I don't understand why.

Greg Weeks

>----- Original Message ----- 
>From: "Greg Weeks" <greg.weeks@timesys.com>
>To: "Ralf Baechle" <ralf@linux-mips.org>
>Cc: <linux-mips@linux-mips.org>
>Sent: Monday, April 11, 2005 21:47
>Subject: Re: another 4kc machine check.
>
>
>  
>
>>This patch appears to fix my machine check problem on the 4kc. The 4kc 
>>shouldn't need an ssnop here, but this appears to fix it.
>>
>>Greg Weeks
>>
>>    
>>
>
>
>--------------------------------------------------------------------------------
>
>
>  
>
>>--- mips-malta4kcle-basic/arch/mips/mm/tlbex.c-orig
>>+++ mips-malta4kcle-basic/arch/mips/mm/tlbex.c
>>@@ -847,7 +847,6 @@
>> 
>>  case CPU_R10000:
>>  case CPU_R12000:
>>- case CPU_4KC:
>>  case CPU_SB1:
>>  case CPU_4KSC:
>>  case CPU_20KC:
>>@@ -874,6 +873,7 @@
>>  tlbw(p);
>>  break;
>> 
>>+ case CPU_4KC:
>>  case CPU_4KEC:
>>  case CPU_24K:
>>  i_ehb(p);
>>
>>    
>>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: another 4kc machine check.
  2005-04-11 20:27         ` Kevin D. Kissell
  2005-04-11 20:27           ` Kevin D. Kissell
  2005-04-12 14:52           ` Greg Weeks
@ 2005-04-12 15:22           ` Maciej W. Rozycki
  2005-04-12 16:38             ` Kevin D. Kissell
  2 siblings, 1 reply; 16+ messages in thread
From: Maciej W. Rozycki @ 2005-04-12 15:22 UTC (permalink / raw)
  To: Kevin D. Kissell; +Cc: Greg Weeks, Ralf Baechle, linux-mips

On Mon, 11 Apr 2005, Kevin D. Kissell wrote:

> If the 4KC and 4KEC need it, so does the 4KSC (and 4KSD).

 But that's weird in the first place as 4Kc implements the original 
revision of MIPS32 so it does not implement "ehb".  Therefore it acts just 
as an ordinary "nop", but according to the 4K manual there is no need for 
one -- the hazard between a move to EntryLo0/EntryLo1 and tlbwi/tlbwr is 
explicitly listed as 0 instructions.

  Maciej

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: another 4kc machine check.
  2005-04-12 15:22           ` Maciej W. Rozycki
@ 2005-04-12 16:38             ` Kevin D. Kissell
  2005-04-12 16:38               ` Kevin D. Kissell
  2005-04-12 16:52               ` Greg Weeks
  0 siblings, 2 replies; 16+ messages in thread
From: Kevin D. Kissell @ 2005-04-12 16:38 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: Greg Weeks, Ralf Baechle, linux-mips

> On Mon, 11 Apr 2005, Kevin D. Kissell wrote:
> 
> > If the 4KC and 4KEC need it, so does the 4KSC (and 4KSD).
> 
>  But that's weird in the first place as 4Kc implements the original 
> revision of MIPS32 so it does not implement "ehb".  Therefore it acts just 
> as an ordinary "nop", but according to the 4K manual there is no need for 
> one -- the hazard between a move to EntryLo0/EntryLo1 and tlbwi/tlbwr is 
> explicitly listed as 0 instructions.

Oops.  Maybe I misread the patch.  I thought the added NOP was between
the TLBWR and the ERET.

            Kevin K.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: another 4kc machine check.
  2005-04-12 16:38             ` Kevin D. Kissell
@ 2005-04-12 16:38               ` Kevin D. Kissell
  2005-04-12 16:52               ` Greg Weeks
  1 sibling, 0 replies; 16+ messages in thread
From: Kevin D. Kissell @ 2005-04-12 16:38 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: Greg Weeks, Ralf Baechle, linux-mips

> On Mon, 11 Apr 2005, Kevin D. Kissell wrote:
> 
> > If the 4KC and 4KEC need it, so does the 4KSC (and 4KSD).
> 
>  But that's weird in the first place as 4Kc implements the original 
> revision of MIPS32 so it does not implement "ehb".  Therefore it acts just 
> as an ordinary "nop", but according to the 4K manual there is no need for 
> one -- the hazard between a move to EntryLo0/EntryLo1 and tlbwi/tlbwr is 
> explicitly listed as 0 instructions.

Oops.  Maybe I misread the patch.  I thought the added NOP was between
the TLBWR and the ERET.

            Kevin K.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: another 4kc machine check.
  2005-04-12 16:38             ` Kevin D. Kissell
  2005-04-12 16:38               ` Kevin D. Kissell
@ 2005-04-12 16:52               ` Greg Weeks
  2005-04-12 19:12                 ` Greg Weeks
  1 sibling, 1 reply; 16+ messages in thread
From: Greg Weeks @ 2005-04-12 16:52 UTC (permalink / raw)
  To: Kevin D. Kissell; +Cc: Maciej W. Rozycki, Ralf Baechle, linux-mips

Kevin D. Kissell wrote:

>>On Mon, 11 Apr 2005, Kevin D. Kissell wrote:
>>
>>    
>>
>>>If the 4KC and 4KEC need it, so does the 4KSC (and 4KSD).
>>>      
>>>
>> But that's weird in the first place as 4Kc implements the original 
>>revision of MIPS32 so it does not implement "ehb".  Therefore it acts just 
>>as an ordinary "nop", but according to the 4K manual there is no need for 
>>one -- the hazard between a move to EntryLo0/EntryLo1 and tlbwi/tlbwr is 
>>explicitly listed as 0 instructions.
>>    
>>
>
>Oops.  Maybe I misread the patch.  I thought the added NOP was between
>the TLBWR and the ERET.
>  
>
No, it adds it before the TLBWR where there shouldn't be a hazard.

Greg Weeks

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: another 4kc machine check.
  2005-04-12 16:52               ` Greg Weeks
@ 2005-04-12 19:12                 ` Greg Weeks
  0 siblings, 0 replies; 16+ messages in thread
From: Greg Weeks @ 2005-04-12 19:12 UTC (permalink / raw)
  To: linux-mips; +Cc: Kevin D. Kissell, Maciej W. Rozycki, Ralf Baechle

Greg Weeks wrote:

> No, it adds it before the TLBWR where there shouldn't be a hazard.

On the off chance that the hazard between the TLBWR and the ERET might 
be coming into play I tried a kernel with 3 nops between the TLBWR and 
ERET and no EHB before the TLBWR and it still machine checks for me.

Greg Weeks

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: another 4kc machine check.
  2005-04-11 19:47       ` Greg Weeks
  2005-04-11 20:27         ` Kevin D. Kissell
  2005-04-11 20:42         ` Kevin D. Kissell
@ 2005-06-10 16:39         ` Chris Wedgwood
  2 siblings, 0 replies; 16+ messages in thread
From: Chris Wedgwood @ 2005-06-10 16:39 UTC (permalink / raw)
  To: Greg Weeks; +Cc: Ralf Baechle, linux-mips

On Mon, Apr 11, 2005 at 03:47:12PM -0400, Greg Weeks wrote:

> This patch appears to fix my machine check problem on the 4kc. The
> 4kc shouldn't need an ssnop here, but this appears to fix it.

This fix is working for me too --- but I've not heard what the
official status of this is and what (if anything) will eventually be
committed.

Does anyone havean update on this from the MIPS people?

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2005-06-10 16:39 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-04-07 14:06 another 4kc machine check Greg Weeks
2005-04-08 14:45 ` Greg Weeks
2005-04-08 16:13   ` Ralf Baechle
2005-04-08 16:45     ` Greg Weeks
2005-04-11 19:47       ` Greg Weeks
2005-04-11 20:27         ` Kevin D. Kissell
2005-04-11 20:27           ` Kevin D. Kissell
2005-04-12 14:52           ` Greg Weeks
2005-04-12 15:22           ` Maciej W. Rozycki
2005-04-12 16:38             ` Kevin D. Kissell
2005-04-12 16:38               ` Kevin D. Kissell
2005-04-12 16:52               ` Greg Weeks
2005-04-12 19:12                 ` Greg Weeks
2005-04-11 20:42         ` Kevin D. Kissell
2005-04-11 20:42           ` Kevin D. Kissell
2005-06-10 16:39         ` Chris Wedgwood

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox