linuxsh-dev

Re: [linuxsh-dev] Caches question

[NIIBE Y. <gn...@ch...>]

Stuart Menefy wrote:
 > This also got me thinking about another potential problem. In
 > update_mmu_cache, the new TLB entry is copied into the TLB using the 
 > LDTLB instruction. This uses the URC bits of the MMUCR register to
 > select the TLB entry to replace, so in effect the TLB replaced is
 > selected at random. If however there is already a TLB entry for this
 > page, then this could cause two TLB entries to refer to the same page,
 > and cause a 'Multiple Hit Exception' when the page is next accessed. I
 > guess the fact that we are not seeing these means that it is not a
 > problem, but I've not convinced myself that it can never occur.
 > 
 > If we have to, it would be pretty easy to fix, effectivly perform
 > a flush_tlb_page before loading the new entry, but this messy.

Is there any case where update_mmu_cache is called with valid entry on
TLB?  As far as I know, there's no such case.

At least, flush_tlb_page is called within mm/memory.c:establish_pte, 
before update_mmu_cache.
-- 

Re: [linuxsh-dev] Caches question

[NIIBE Y. <gn...@ch...>]

Stuart Menefy wrote:
 > You're right, it has the same synonym problem, due to cache size vs.
 > page size issues. However there is one important difference, the
 > hardware detects the synonym, and raises an exception when it would be
 > created.

Interesting point.  Yes, we can find the similarity between MIPS and
SuperH, but there're the differences we should watch out.

 > This has advantages and disadvantages:
 >  - the advantage is that, although there is a performance penalty,
 >    there sould be no risk of errors caused by synonyms
 >  - however it does prevent legitimate synonyms, for example when all
 >    the mappings are read only.
 > 
 > SH4 doesn't have this detection capability, so we have to make sure
 > we catch any problems early.

Yes.

 > The other point at which synonyms can occur is when a page is explicitly
 > mapped at multiple addresses in user space. So I had a go at writing a
 > simple test case for this, and then fixing the problem. Attached is my
 > test code, and a potential fix. This is taken almost unchanged from 
 > the Sparc sun4c code, which has a completely virtual cache. Its horrible,
 > but I don't see any alternative, unless we can restrict the addresses
 > at which shared pages can be mapped.

OK.  The point is that:
	When there's shared mapping which causes the alias (synonym)
	we fix-up the pte(s) so that the data should not on the caches.
	Specifically, on the TLB fault of the page (of WRITE&&SHARED), 
	we fix-up the all the pte as uncachablie page.

 >  void update_mmu_cache(struct vm_area_struct * vma,
 >  		      unsigned long address, pte_t pte)
 >  {
 > @@ -276,6 +352,11 @@
 >  	unsigned long pteaddr;
 >  
 >  	save_and_cli(flags);
 > +
 > +#ifdef __SH4__
 > +	if ((vma->vm_flags & (VM_WRITE|VM_SHARED)) == (VM_WRITE|VM_SHARED))
 > +		synonym_fixup(vma, address, pte);
 > +#endif
 >  
 >  	/* Set PTEH register */
 >  	if (vma) {

This part, agreed.

There's a point which I can't understand.

 > diff -u -r1.11 fault.c
 > --- arch/sh/mm/fault.c	2000/05/18 09:34:18	1.11
 > +++ arch/sh/mm/fault.c	2000/06/23 17:58:48
 > @@ -268,6 +268,82 @@
 >  		goto no_context;
 >  }
 >  
 > +#ifdef __SH4__
 > +/* There are really two cases of aliases to watch out for, and these
 > + * are:
 > + *
 > + *     1) A user's page which can be aliased with the kernels virtual
 > + *        mapping of the physical page.
 > + *
 > + *     2) Multiple user mappings of the same inode/anonymous object
 > + *        such that two copies of the same data for the same phys page
 > + *        can live (writable) in the cache at the same time.
 > + *
 > + * We handle number 1 by flushing the kernel copy of the page always
 > + * after COW page operations.
 > + */
 > +static void synonym_fixup(struct vm_area_struct *vma, unsigned long address, pte_t pte)
 > +{
 > +	pgd_t *pgdp;
 > +	pte_t *ptep;
 > +
 > +	if (vma->vm_file) {
 > +		struct address_space *mapping;
 > +		unsigned long offset = (address & PAGE_MASK) - vma->vm_start;
 > +		struct vm_area_struct *vmaring;
 > +		int alias_found = 0;
 > +
 > +		mapping = vma->vm_file->f_dentry->d_inode->i_mapping;
 > +		spin_lock(&mapping->i_shared_lock);
 > +		vmaring = mapping->i_mmap; 

Here, we loop the mapping ring.

 > +		do {
 > +			unsigned long vaddr = vmaring->vm_start + offset;
 > +			unsigned long start;
 > +
 > +			/* Do not mistake ourselves as another mapping. */
 > +			if (vmaring == vma)
 > +				continue;
 > +
 > +			printk("Found a shared mapping\n");

Yes, we found the shared mapping.

 > +			if ((vaddr ^ address) & 0x3000) {
 > +				printk("Found an synonym problem\n");
 > +				alias_found++;

Yup, we found the synonym (in terms of SuperH.  In general "alias").

 > +				start = vmaring->vm_start;
 > +				/* If this is already in the cache flush it,
 > +				 * and remove any existing TLB entries. */
 > +				while (start < vmaring->vm_end) {

But why we loop from the start of the area (and to the end) to fix up the
pte-s?  Isn't that fixing up the relevant one-page enough?  Even if we
fixed the pte-s of the counter parts of the area, another TLB fault of
different page will come here again.

 > +					pgdp = pgd_offset(vmaring->vm_mm, start);
 > +					if (!pgdp)
 > +						goto next;
 > +					ptep = pte_offset((pmd_t *) pgdp, start);
 > +					if (!ptep)
 > +						goto next;
 > +
 > +					if (pte_val(*ptep) & _PAGE_PRESENT) {
 > +						printk("..and the page is present\n");
 > +						flush_cache_page(vmaring, start);
 > +						*ptep = __pte(pte_val(*ptep) &
 > +							      (~ _PAGE_CACHABLE));
 > +						flush_tlb_page(vmaring, start);
 > +					}
 > +				next:
 > +					start += PAGE_SIZE;
 > +				}

In my understanding, I think that this loop is questionable.

 > +			}
 > +		} while ((vmaring = vmaring->vm_next_share) != NULL);
 > +		spin_unlock(&mapping->i_shared_lock);
 > +
 > +		if (alias_found && (pte_val(pte) & _PAGE_CACHABLE)) {
 > +			printk("updating PTE\n");
 > +			pgdp = pgd_offset(vma->vm_mm, address);
 > +			ptep = pte_offset((pmd_t *) pgdp, address);
 > +			*ptep = __pte(pte_val(*ptep) & (~ _PAGE_CACHABLE));
 > +			pte = *ptep;
 > +		}
 > +	}
 > +}
 > +#endif
 > +
-- 

[linuxsh-dev] Re: DELIVERY FAILURE: Error transferring to LAVA.LINEO.COM

[Mitch D. <mj...@al...>]

Hello,

Recently we've had some bounced messages sent back to the
mailing list.  This should now cease.

Regards,

Mitch.
--
mailto:mj...@al... | Certified Linux Evangelist!

Re: [linuxsh-dev] Caches question

[Stuart M. <Stu...@st...>]

Niibe-san

I got both your mails about the cache problem. Thanks for confirming my
thoughts, and I'll post something on the kernel mailing list about
this. However your first mail raised some interesting questions.

>  > Note this is on an SH4, so to some extent we have to regard the cache
>  > as virtual.
> 
> More specifically, SH-4 has virtually tagged and physically indexed
> cache system.  I think that MIPS R4000 has same system.

This was what I thought, until I started looking at it yesterday.
You're right, it has the same synonym problem, due to cache size vs.
page size issues. However there is one important difference, the
hardware detects the synonym, and raises an exception when it would be
created.

This has advantages and disadvantages:
 - the advantage is that, although there is a performance penalty,
   there sould be no risk of errors caused by synonyms
 - however it does prevent legitimate synonyms, for example when all
   the mappings are read only.

SH4 doesn't have this detection capability, so we have to make sure
we catch any problems early.

The other point at which synonyms can occur is when a page is explicitly
mapped at multiple addresses in user space. So I had a go at writing a
simple test case for this, and then fixing the problem. Attached is my
test code, and a potential fix. This is taken almost unchanged from 
the Sparc sun4c code, which has a completely virtual cache. Its horrible,
but I don't see any alternative, unless we can restrict the addresses
at which shared pages can be mapped.

This also got me thinking about another potential problem. In
update_mmu_cache, the new TLB entry is copied into the TLB using the 
LDTLB instruction. This uses the URC bits of the MMUCR register to
select the TLB entry to replace, so in effect the TLB replaced is
selected at random. If however there is already a TLB entry for this
page, then this could cause two TLB entries to refer to the same page,
and cause a 'Multiple Hit Exception' when the page is next accessed. I
guess the fact that we are not seeing these means that it is not a
problem, but I've not convinced myself that it can never occur.

If we have to, it would be pretty easy to fix, effectivly perform
a flush_tlb_page before loading the new entry, but this messy.

Any thoughts?

> Generally speaking, I don't think we need flush at the time of EXIT.
> We can postpone the flush at the time of reuse of the physical memory
> (or if the memory is overwritten, we don't need to flush them).

Agreed. However I came across an email from Linus (admitidly written
way back in 1995) where he said that he preferred flushing when a page
was freed, as this is likly to be less time critical than when it is
allocated. This appears to be the way the kernel implements things.

Stuart

------------------------------------------------------------------------------
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#include <stdio.h>

#define SIZE (1024)

main()
{
  volatile int *p1, *p2;
  int fd;
  int i;
  int count;

  printf("Test running\n");
  fd = open("/tmp/xx", O_RDWR | O_CREAT, 0666);
  if (fd < 0) {
    perror("Failed to open file");
    exit(1);
  }
  for (i=0; i<SIZE; i++) {
    int dummy = 0;
    write(fd, &dummy, sizeof(int));
  }

  p1 = mmap(NULL, SIZE * sizeof(int), PROT_READ | PROT_WRITE, 
	    MAP_SHARED, fd, 0);
  if (p1 == MAP_FAILED) {
    perror("First mmap failed");
    exit(1);
  }
  p2 = mmap(p1 + SIZE, SIZE * sizeof(int), PROT_READ | PROT_WRITE,
	    MAP_FIXED | MAP_SHARED, fd, 0);
  if (p2 == MAP_FAILED) {
    perror("Second mmap failed");
    exit(1);
  }

  /* access the second mapping here, so that the TLB is set up, this
   * way we don't take a fault on the first access, which might cause
   * a flush. */
  p2[0] = 1;

  printf("Running test\n");
  for (i=0; i<SIZE; i++) {
    p1[i] = i;
  }

  count = 0;
  for (i=0; i<SIZE; i++) {
    int j;
    j = p2[i];
    if (j != i) {
      printf("Diff at 0x%x (read 0x%x)\n", i, j);
      count++;
    }
  }
  printf("Differences: %d\n", count);

  printf("Finished\n");
}
------------------------------------------------------------------------------
Index: arch/sh/mm/fault.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/fault.c,v
retrieving revision 1.11
diff -u -r1.11 fault.c
--- arch/sh/mm/fault.c	2000/05/18 09:34:18	1.11
+++ arch/sh/mm/fault.c	2000/06/23 17:58:48
@@ -268,6 +268,82 @@
 		goto no_context;
 }
 
+#ifdef __SH4__
+/* There are really two cases of aliases to watch out for, and these
+ * are:
+ *
+ *     1) A user's page which can be aliased with the kernels virtual
+ *        mapping of the physical page.
+ *
+ *     2) Multiple user mappings of the same inode/anonymous object
+ *        such that two copies of the same data for the same phys page
+ *        can live (writable) in the cache at the same time.
+ *
+ * We handle number 1 by flushing the kernel copy of the page always
+ * after COW page operations.
+ */
+static void synonym_fixup(struct vm_area_struct *vma, unsigned long address, pte_t pte)
+{
+	pgd_t *pgdp;
+	pte_t *ptep;
+
+	if (vma->vm_file) {
+		struct address_space *mapping;
+		unsigned long offset = (address & PAGE_MASK) - vma->vm_start;
+		struct vm_area_struct *vmaring;
+		int alias_found = 0;
+
+		mapping = vma->vm_file->f_dentry->d_inode->i_mapping;
+		spin_lock(&mapping->i_shared_lock);
+		vmaring = mapping->i_mmap; 
+		do {
+			unsigned long vaddr = vmaring->vm_start + offset;
+			unsigned long start;
+
+			/* Do not mistake ourselves as another mapping. */
+			if (vmaring == vma)
+				continue;
+
+			printk("Found a shared mapping\n");
+			if ((vaddr ^ address) & 0x3000) {
+				printk("Found an synonym problem\n");
+				alias_found++;
+				start = vmaring->vm_start;
+				/* If this is already in the cache flush it,
+				 * and remove any existing TLB entries. */
+				while (start < vmaring->vm_end) {
+					pgdp = pgd_offset(vmaring->vm_mm, start);
+					if (!pgdp)
+						goto next;
+					ptep = pte_offset((pmd_t *) pgdp, start);
+					if (!ptep)
+						goto next;
+
+					if (pte_val(*ptep) & _PAGE_PRESENT) {
+						printk("..and the page is present\n");
+						flush_cache_page(vmaring, start);
+						*ptep = __pte(pte_val(*ptep) &
+							      (~ _PAGE_CACHABLE));
+						flush_tlb_page(vmaring, start);
+					}
+				next:
+					start += PAGE_SIZE;
+				}
+			}
+		} while ((vmaring = vmaring->vm_next_share) != NULL);
+		spin_unlock(&mapping->i_shared_lock);
+
+		if (alias_found && (pte_val(pte) & _PAGE_CACHABLE)) {
+			printk("updating PTE\n");
+			pgdp = pgd_offset(vma->vm_mm, address);
+			ptep = pte_offset((pmd_t *) pgdp, address);
+			*ptep = __pte(pte_val(*ptep) & (~ _PAGE_CACHABLE));
+			pte = *ptep;
+		}
+	}
+}
+#endif
+
 void update_mmu_cache(struct vm_area_struct * vma,
 		      unsigned long address, pte_t pte)
 {
@@ -276,6 +352,11 @@
 	unsigned long pteaddr;
 
 	save_and_cli(flags);
+
+#ifdef __SH4__
+	if ((vma->vm_flags & (VM_WRITE|VM_SHARED)) == (VM_WRITE|VM_SHARED))
+		synonym_fixup(vma, address, pte);
+#endif
 
 	/* Set PTEH register */
 	if (vma) {

re: [linuxsh-dev] Ramdisk

[Studencki (e. P. <Paw...@er...>]

Hello,

Jaswinder, thanks for your help.

the problem is, i have already:
int rd_size = 4096;             /* Size of the RAM disks */

and wenn I'm trying to use RAM disk 4 MB I get these errors:
-------------------------------------------------------------------
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 4096 blocks [1 disk] into ram disk... <1>Unable to handle
kernel NULL pointer dereference at virtual address 00000000
pc = 8c00d842
Oops: 0001

PC  : 8c00d842 SP  : 8c1fbb20 SR  : 400001f1 TEA : 00000000
R0  : 400001f1 R1  : 00000000 R2  : 40000101 R3  : 8c1fbb34
R4  : 00000000 R5  : 00000000 R6  : 8c07fb14 R7  : 00000000
R8  : 00000000 R9  : 00000001 R10 : 00000400 R11 : 8ce8faa0
R12 : 8c1fa000 R13 : 8c081a3c R14 : 8c1fbb20
---------------------------------------------------------------------

After Your mail, I've increased size rd_size to 8192, but it doesn't
help...and I'm still using 2 MB RAM disk...

maybe has somebody tried to hard code kernel options (ramdisk_size,
ramdisk_start, mem etc.) ??
( I changed only arch/sh/kernel/setup.c, function parse_mem_cmdline, line 
memory_start = (unsigned long)PAGE_OFFSET+__MEMORY_START;
        /* Default is 4Mbyte. */
        memory_end = (unsigned long)PAGE_OFFSET+0x01000000+__MEMORY_START;
	
^^^^^^^^^^^^----- 16 MB RAM
 should I also modify variables argv_init, envp_init in init/main.c ? 
 or it is all a wrong way to solve this problem?


Regards
Pawel

Re: [linuxsh-dev] Ramdisk

[Jaswinder S. <jas...@ya...>]

--- "Studencki (external) Pawel"
<Paw...@er...> wrote:
> Hello,

Hello ,

> Has somebody same problems with bigger RAM disks ?
> How much space does kernel need ? 

If you want bigger Ramdisk .
increase the buffers and variables used by "rd.c"
which is normally set to 4096 . please increase it to
suit your requirement.

I am not sitting on my computer so i can not tell you
the name of buffers and variables but they are defined
in "rd.c" and they are set at 4096. find it your self.
ok .

and do one thing make your RAMDISK again with proper
count in "dd" command , which suits your requirement.
check that the process of making RAMDISK should be
error-free. 

Regards,

Jaswinder.


__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

[linuxsh-dev] Caches question

[NIIBE Y. <gn...@ch...>]

Sorry Stuart.  Your analysis is right.  I'm always wrong. :-)

NIIBE Yutaka wrote:
 > Stuart Menefy wrote:
 >  > I've been battling against a problem for a couple of days now, which looks
 >  > like a 'generic' kernel problem, but it like to run it past you first.
 > 
 > I know the battle is quite annoying...
 > 
 >  > Note this is on an SH4, so to some extent we have to regard the cache
 >  > as virtual.
 > 
 > More specifically, SH-4 has virtually tagged and physically indexed
 > cache system.  I think that MIPS R4000 has same system.
 > 
 > Generally speaking, I don't think we need flush at the time of EXIT.
 > We can postpone the flush at the time of reuse of the physical memory
 > (or if the memory is overwritten, we don't need to flush them).
 > 
 >  > As far as I can tell, the exact problem I have is this
 >  >  - a page is allocated and mapped into a process's address space
 >  >    (I think its part of the stack) and is written to. The written
 >  >    data ends up in the cache as normal.
 >  >  - the process then exits, and all the pages are freed.
 >  >  - later another process executes a fork, and so the kernel needs to
 >  >    allocate a page for the child process's pgd, and picks
 >  >    the page which was previously part of the first processes stack
 >  >  - the pgd for the child process is copied from the parent to the child
 >  >    into the newly allocated page
 >  >  - as part of duplicating the memory map for the child a
 >  >    flush_cache_mm is called, which results in the entire cache being
 >  >    flushed, including the data which was cached right at the beginning
 >  >    of this description. This overwrites the pgd with garbage, and later
 >  >    causes errors to be reported.
 > 
 > I think that this (corrupt of the pgd) can't be happened in this
 > sequence.  The page allocated for PGD is initialized by get_pgd_slow
 > (overwritten).

Sorry, I misunderstood.  The currupts will occur, when the page was
mapped to the user space and there's cache alias.

I checked the code, the page allocation code does not include any
cache flush.

Hence, your patch is the right solution.
-- 

[linuxsh-dev] Caches question

[NIIBE Y. <gn...@ch...>]

Stuart Menefy wrote:
 > I've been battling against a problem for a couple of days now, which looks
 > like a 'generic' kernel problem, but it like to run it past you first.

I know the battle is quite annoying...

 > Note this is on an SH4, so to some extent we have to regard the cache
 > as virtual.

More specifically, SH-4 has virtually tagged and physically indexed
cache system.  I think that MIPS R4000 has same system.

Generally speaking, I don't think we need flush at the time of EXIT.
We can postpone the flush at the time of reuse of the physical memory
(or if the memory is overwritten, we don't need to flush them).

 > As far as I can tell, the exact problem I have is this
 >  - a page is allocated and mapped into a process's address space
 >    (I think its part of the stack) and is written to. The written
 >    data ends up in the cache as normal.
 >  - the process then exits, and all the pages are freed.
 >  - later another process executes a fork, and so the kernel needs to
 >    allocate a page for the child process's pgd, and picks
 >    the page which was previously part of the first processes stack
 >  - the pgd for the child process is copied from the parent to the child
 >    into the newly allocated page
 >  - as part of duplicating the memory map for the child a
 >    flush_cache_mm is called, which results in the entire cache being
 >    flushed, including the data which was cached right at the beginning
 >    of this description. This overwrites the pgd with garbage, and later
 >    causes errors to be reported.

I think that this (corrupt of the pgd) can't be happened in this
sequence.  The page allocated for PGD is initialized by get_pgd_slow
(overwritten).

If the corrupt of the memory occurs, the sequence would be like this:

   (1) There's the cache entry, say, for the virtual address
       VIRT, for physicall address PHYS.

   (2) (In some reason (bug)) the flush doesn't occur, where it
       should.

   (3) The page of PHYS are allocated to different purpose.

   (4) Some memory access occurs which invalidate VIRT.  The entry is
       flushed and currupts the data at PHYS.  Totally unrelated data
       is written back to physical memory.

Your patch may change the behavior as it flushes the cache at the time
of exit system call.  However, I suspect there's real bug at other
place.
-- 

Re: [linuxsh-dev] patch: Multiple SCI(F)s support

[Stuart M. <Stu...@st...>]

Jaswinder

What, you mean you're not a member of the 38400 inner circle klub (or
'THICK' as it is fondly known) ? What is the world coming to...? Well,
much as I'd like to, I can't divulge the secrets of the society,
otherwise I'd risk losing all privileges (the golden D-type, the social
company of fellow members, my life, that sort of thing). And I'm not
sure I could describe the secret handshake in ASCII graphics anyway.

On the other hand, it could just be force of habit. That is as fast as
some slow embedded devices can go without risking dropping characters,
but fast enough to be usable for human interactions, so it is what I
tend to use. Boring answer I'm afraid.

Stuart


On Jun 20, 10:30pm, jas...@ya... wrote:
> Subject: Re: [linuxsh-dev] patch: Multiple SCI(F)s support
> 
> hello linux-dev group,
> 
> --- Stuart Menefy <Stu...@st...> wrote:
> 
> > On processors which have two serial ports:
> >   SCI  : ttyS0
> >   SCIF : ttyS1
> > so if you want to use the SCIF as a console, add a
> > command line option
> > along the lines of:
> >   console=ttyS1,38400
> 
> Can somebody tell me why you set SCIF to 38400 and
> kojima san also set their SCIF to 38400 in 2.2.12.
> 
> Is their any secret ? 
> please disclose it. :) :)
> 
> thanks .
> 
> BTW, I set my SCIF to 115200 .
> 
> Regards,
> 
> Jaswinder
> 
> __________________________________________________
> Do You Yahoo!?
> Send instant messages with Yahoo! Messenger.
> http://im.yahoo.com/
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/mailman/listinfo/linuxsh-dev
>-- End of excerpt from jas...@ya...

[linuxsh-dev] Multiple SCI(F) changes checked in

[Stuart M. <Stu...@st...>]

Folks

I've checked in the changes for the multiple SCI(F) support which I
posted as a patch a few days ago. Sorry it took a little longer than
expected, but the cache problem I reported yesterday only appeared
with these changes in place, and I wanted to make sure I hadn't broken
anything. Turned out it was just the slight shifting of memory contents
which provoked the problem.

Many thanks for the fixes from Niibe-san and Jaswinder, I've included
them in this check in. There is also a suggested configuration for the
IRDA port on a 7709A, but it will need a bit more work, because there
is no code to configure the interrupts on this device yet.

This check-in also makes the change in major/minor device numbers
suggested by Niibe-san, and includes support for 16550 compatible
serial ports. The configuration is correct for the 7750 SolutionEngine,
but should work on other boards with little or no changes.

So you can now have console set to SCI, SCIF or 16550, or both. For
example:
  console=ttySC1,38400 console=ttyS0,115200
will send kernel messages to both ports at the same time, while
/dev/console is mapped to whichever console is specified last on the
command line.

Have fun!

Stuart

[linuxsh-dev] Caches question

[Stuart M. <Stu...@st...>]

Folks

I've been battling against a problem for a couple of days now, which looks
like a 'generic' kernel problem, but it like to run it past you first.

Note this is on an SH4, so to some extent we have to regard the cache
as virtual.

As far as I can tell, the exact problem I have is this
 - a page is allocated and mapped into a process's address space
   (I think its part of the stack) and is written to. The written
   data ends up in the cache as normal.
 - the process then exits, and all the pages are freed.
 - later another process executes a fork, and so the kernel needs to
   allocate a page for the child process's pgd, and picks
   the page which was previously part of the first processes stack
 - the pgd for the child process is copied from the parent to the child
   into the newly allocated page
 - as part of duplicating the memory map for the child a
   flush_cache_mm is called, which results in the entire cache being
   flushed, including the data which was cached right at the beginning
   of this description. This overwrites the pgd with garbage, and later
   causes errors to be reported.

Note that the page is effectively mapped at two virtual addresses in
this sequence, once in user space and once in kernel space. By chance
these addresses are such that a cache synonym occurs (ie a given physical
address maps to different cache lines).

Now, as far as I can see this is a generic problem. When a process
terminates, the data in the cache is not invalidated. For any system with
a virtual cache, there is a chance that the page will be reused before the
cache is flushed.

Looking at the code, this appears to only be a problem when a process exits.
Every other place I've looked, when a page is unmapped from a user address
space (or even kernel address through vmalloc), that address range is first
flushed.

So, I've put together this small patch which solves the specific problem
I am seeing (there is a lot of context so you can see what is happening,
but only two changes).  I'm not even sure the flush_tlb is needed,
certainly not on an SH, and probably not ever, but it doesn't do any harm
(except to performance!).

Before I make a fool of myself on the kernel mailing list I'd appreciate
any comments you can give.

Stuart

Index: mm/mmap.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/mm/mmap.c,v
retrieving revision 1.1.1.3
diff -U30 -r1.1.1.3 mmap.c
--- mm/mmap.c	2000/04/29 15:46:04	1.1.1.3
+++ mm/mmap.c	2000/06/21 22:45:50
@@ -832,61 +832,63 @@
 		avl_insert(vma, &mm->mmap_avl);
 }
 
 /* Release all mmaps. */
 void exit_mmap(struct mm_struct * mm)
 {
 	struct vm_area_struct * mpnt;
 
 	release_segments(mm);
 	mpnt = mm->mmap;
 	vmlist_modify_lock(mm);
 	mm->mmap = mm->mmap_avl = mm->mmap_cache = NULL;
 	vmlist_modify_unlock(mm);
 	mm->rss = 0;
 	mm->total_vm = 0;
 	mm->locked_vm = 0;
 	while (mpnt) {
 		struct vm_area_struct * next = mpnt->vm_next;
 		unsigned long start = mpnt->vm_start;
 		unsigned long end = mpnt->vm_end;
 		unsigned long size = end - start;
 
 		if (mpnt->vm_ops) {
 			if (mpnt->vm_ops->unmap)
 				mpnt->vm_ops->unmap(mpnt, start, size);
 			if (mpnt->vm_ops->close)
 				mpnt->vm_ops->close(mpnt);
 		}
 		mm->map_count--;
 		remove_shared_vm_struct(mpnt);
+		flush_cache_range(mm, start, end);
 		zap_page_range(mm, start, size);
+		flush_tlb_range(mm, start, end);
 		if (mpnt->vm_file)
 			fput(mpnt->vm_file);
 		kmem_cache_free(vm_area_cachep, mpnt);
 		mpnt = next;
 	}
 
 	/* This is just debugging */
 	if (mm->map_count)
 		printk("exit_mmap: map count is %d\n", mm->map_count);
 
 	clear_page_tables(mm, FIRST_USER_PGD_NR, USER_PTRS_PER_PGD);
 }

[linuxsh-dev] Ramdisk

[Studencki (e. P. <Paw...@er...>]

Hello,

I have again :) problem with my RAM disk... I think it's hte problem with
memory allocation... I was using 2 MB RAM disk with mem=16 MB, than I've
made 4 MB disk and this kernel messages:

===================================
Linux version 2.3.99-pre7 (root@capella) (gcc version 2.95.2 19991024
(release))
 #182 Wed Jun 21 11:56:49 MEST 2000
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
SH RTC: invalid value, resetting to 1 Jan 2000
CPU clock: 75.18MHz
Module clock: 75.18MHz
Interval = 187973
Calibrating delay loop... 149.91 BogoMIPS
Memory: 11304k/16384k available (496k kernel code, 5080k reserved, 31k data,
20k
 init)
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
kmem_create: Poisoning requested, but con given - bdev_cache
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
kmem_create: Poisoning requested, but con given - inode_cache
CPU: SH7708/SH7709
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.3
Based upon Swansea University Computer Society NET3.039
kmem_create: Poisoning requested, but con given - skbuff_head_cache
Starting kswapd v1.6
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 4096 blocks [1 disk] into ram disk... <1>Unable to handle
kerne
l NULL pointer dereference at virtual address 00000000
pc = 8c00d842
Oops: 0001

PC  : 8c00d842 SP  : 8c1fbb20 SR  : 400001f1 TEA : 00000000
R0  : 400001f1 R1  : 00000000 R2  : 40000101 R3  : 8c1fbb34
R4  : 00000000 R5  : 00000000 R6  : 8c07fb14 R7  : 00000000
R8  : 00000000 R9  : 00000001 R10 : 00000400 R11 : 8ce8faa0
R12 : 8c1fa000 R13 : 8c081a3c R14 : 8c1fbb20
MACH: 03a8fdc2 MACL: 0001aae0 GBR : ffffffff PR  : 8c02a8a0
====================================================================

this problem is similar to problem Yutarou Ebihara (function
wake_up_process, kernel is trying to use wrong RAM area ?) I have the same
problem with smaller RAM disk at mem=4 or 8 MB, so I think, it depends on
memory allocation...)
Has somebody same problems with bigger RAM disks ?
How much space does kernel need ? 
I'm using Ludovic's Loader. Kernel Start in RAM is 0x8c001000 and initrd
starts in RAM at 0x8c800000, I left enough space for Kernel ?

thanks for any suggestions

Regards
Pawel

Re: [linuxsh-dev] patch: Multiple SCI(F)s support

[Jaswinder S. <jas...@ya...>]

hello linux-dev group,

--- Stuart Menefy <Stu...@st...> wrote:

> On processors which have two serial ports:
>   SCI  : ttyS0
>   SCIF : ttyS1
> so if you want to use the SCIF as a console, add a
> command line option
> along the lines of:
>   console=ttyS1,38400

Can somebody tell me why you set SCIF to 38400 and
kojima san also set their SCIF to 38400 in 2.2.12.

Is their any secret ? 
please disclose it. :) :)

thanks .

BTW, I set my SCIF to 115200 .

Regards,

Jaswinder

__________________________________________________
Do You Yahoo!?
Send instant messages with Yahoo! Messenger.
http://im.yahoo.com/

Re: [linuxsh-dev] Re: [linux-sh:01005] Logos

[Greg B. <gn...@al...>]

YAEGASHI Takeshi wrote:
> 
> > I was bored today (see [linux-sh:01001]) so I worked up some
> > LinuxSH boot logos,
>
> So nice. :-> At once I'd integrated the red logo version(#2)
> into my kernel.  Thank you.

  My pleasure.

> > The default Linux monochrome logo is truly atrocious, and needed a
> > lot of manual tweaking to be recognisable as Tux.  Does anyone
> > actually use the monochrome logo?
> 
> Sufficiently good.  It would give a much better impression to
> those to whom I demonstrate than the standard logo does.

  Good.  After all the entire reason for the logo is to look good
at demonstrations ;-)


Greg.
-- 
Fight spam http://www.caube.org.au/
If it's a choice between being a paranoid, hyper-suspicious global
village
idiot, or a gullible, mega-trusting sheep, I don't look good in mint
sauce. 
 - jd, slashdot, 11Feb2000.

[linuxsh-dev] Re: [linux-sh:01005] Logos

[YAEGASHI T. <yae...@ma...>]

> I was bored today (see [linux-sh:01001]) so I worked up some
> LinuxSH boot logos, in answer to Yaegashi-san's request of
> 11 days ago.  You can see my efforts at 
> 
> http://www.alphalink.com.au/~gnb/logo-vote/index.cgi
> 
> and you can vote for the one you like (ok, I was *really* bored).
> Please don't hesitate to mail me any constructive comments
> and suggestions.

So nice. :-> At once I'd integrated the red logo version(#2)
into my kernel.  Thank you.


> Note that the first batch are all simply derived from the
> default Linux logos with a title superimposed on them.  This
> because I was bored, not inspired.
>
> The default Linux monochrome logo is truly atrocious, and needed a
> lot of manual tweaking to be recognisable as Tux.  Does anyone
> actually use the monochrome logo?

Sufficiently good.  It would give a much better impression to
those to whom I demonstrate than the standard logo does.

--
YAEGASHI Takeshi <yae...@ma...>

Re: [linuxsh-dev] Kernel merge

[YAEGASHI T. <yae...@ma...>]

> With linux-2.4.0-test1-ac20, almost all is in sync.

Thank you very much for taking care of us. :->


> The patches remain around:
> 	(1) Documentation/Configure.help
> 	(2) drivers/net/ne.c
> 	(3) files under net/ for CONFIG_NET == 0
> 
> I think that (2) is by Takeshi.  With new I/O handling, I guess that
> this is not needed any more.  Is that correct?

Yes, I think so, though it seems to me unsigned is suitable for
I/O port addresses.  Anyway it's solved and I don't mind any
more.

--
YAEGASHI Takeshi <yae...@ma...>

Re: [linuxsh-dev] patch: Multiple SCI(F)s support

[YAEGASHI T. <yae...@ma...>]

Hello Stuart,

Sorry I don't test "multiple" feature of your patch yet.  It
seems quite easy to add support for more SCIF(IrDA).

I see it works on my HP690(SCIF only).  But according to
/proc/interrupts, it seems to me that somewhat too many TXI
interrupts occur.


--- 352,369 ----
        }
  
        save_and_cli(flags);
!       ctrl = sci_in(port, SCSCR);
        if (port->gs.xmit_cnt == 0) {
                ctrl &= ~SCI_CTRL_FLAGS_TIE;
                port->gs.flags &= ~GS_TX_INTEN;
        } else {
!               if (port->type == PORT_SCIF) {
!                       sci_in(port, SCxSR); /* Dummy read */
!                       sci_out(port, SCxSR, SCIF_TDFE);

I think this should be: sci_out(port, SCxSR, ~SCIF_TDFE);
Correct?


And at first it cannnot communicate at 115.2Kbps because of the
insufficient precision of clock measurement.  This change might
be needed to improve it...

--- sh-sci.h.orig       Tue Jun 20 14:27:12 2000
+++ sh-sci.h    Tue Jun 20 14:27:30 2000
@@ -264,7 +264,7 @@
 
 #define PCLK           (current_cpu_data.module_clock)
 
-#define SCBRR_VALUE(bps) (PCLK/(32*bps)-1)
+#define SCBRR_VALUE(bps) ((PCLK+16*bps)/(32*bps)-1)
 #define BPS_2400       SCBRR_VALUE(2400)
 #define BPS_4800       SCBRR_VALUE(4800)
 #define BPS_9600       SCBRR_VALUE(9600)



> Please check in.  Then, let's assign new device number for it.
> I think that we need CONFIG_SCI_SERIAL again.
> 
> The rationale for new device number is: some boards has same serial
> chip as PC and he may want to use standard serial driver.

Yes, please go ahead with checking in.  I would like to drive
16550A's in HD64461.

--
YAEGASHI Takeshi <yae...@ma...>

[linuxsh-dev] Kernel merge

[NIIBE Y. <gn...@ch...>]

With linux-2.4.0-test1-ac20, almost all is in sync.

The patches remain around:
	(1) Documentation/Configure.help
	(2) drivers/net/ne.c
	(3) files under net/ for CONFIG_NET == 0

I think that (2) is by Takeshi.  With new I/O handling, I guess that
this is not needed any more.  Is that correct?
-- 

[linuxsh-dev] Logos

[Greg B. <gn...@al...>]

G'day

I was bored today (see [linux-sh:01001]) so I worked up some
LinuxSH boot logos, in answer to Yaegashi-san's request of
11 days ago.  You can see my efforts at 

http://www.alphalink.com.au/~gnb/logo-vote/index.cgi

and you can vote for the one you like (ok, I was *really* bored).
Please don't hesitate to mail me any constructive comments
and suggestions.

Note that the first batch are all simply derived from the
default Linux logos with a title superimposed on them.  This
because I was bored, not inspired.

The default Linux monochrome logo is truly atrocious, and needed a
lot of manual tweaking to be recognisable as Tux.  Does anyone
actually use the monochrome logo?


Greg.
-- 
Fight spam http://www.caube.org.au/
If it's a choice between being a paranoid, hyper-suspicious global
village
idiot, or a gullible, mega-trusting sheep, I don't look good in mint
sauce. 
 - jd, slashdot, 11Feb2000.

[linuxsh-dev] Frustrated with our 7750 board....

[NIIBE Y. <gn...@ch...>]

To the lin...@li..., mj...@al... wrote:
 > We seem to be having a run of bad luck with our Hitachi 7750
 > board, and we're wondering if anyone else can give us some
 > tips.

I've changed the forum to lin...@m1..., where I think the
topic is relevant.

 > First, we are able to upload S-records from Windows 
 > Hyperterminal to the board just fine, but we're unable
 > to upload even the smallest programs using Minicom or
 > "cat" or the mouse from Linux.  The symptoms are that
 > the board starts spitting a message saying 
 > "Error: InDev0Buff was full.".  Any ideas?

I believe that the error is from the ROM monitor.  As there's
no flow control feature, the buffer is overflowed.

You need ****PAUSE**** here, as there's no flow control.

 > Second, we would like to try Niibe-san's gdb stub.  But
 > we are unable to get the "fl" command to write to the
 > flash memory.
 > 
 > We type "fl", the flash image gets moved to RAM, we upload
 > the S-records for a short program, the flash gets programmed,
 > but when we do a "md 01000000" to see the flash, it's still
 > all 0xff.  Any ideas?
 > 
 > Any help would be most appreciated.

You need to specify ***OFFSET*** to the fl command here.

---------------------- Excerpt from the article I posted:

In my case, I have to set MD[2:0] ON-OFF-OFF and specify the clock
rate 6:2:1 (CPU 200MHz, Bus 66MHz, Module 33MHz), to stabilize it.

In case of Busclock=33MHz, I faced sudden stop/reset of the system, as
I've reported.  I don't know why.

Currently, it works fine for me.

To write gdb-stub image to the flash rom, I used Kermit like follows.

---------------------- Kermit
> set line /dev/ttyS0
> set speed 115200
> binary
> set transmit pause 1
----------------------  On the monitor (FLash command)
Ready> fl a0000000
---------------------- Kermit to send gdb-stub S-record
> transmit gdb-sh-stub/sh-stub.srec
----------------------

You need some "pause" as there's no protocol to control the flow.

But I don't recommend so much using GDB stub, as it's not good, no
user interface.  If you'd like hacking, please try it out.
-- 

[linuxsh-dev] Frustrated with our 7750 board....

[<mj...@al...>]

Hi Guys,

We seem to be having a run of bad luck with our Hitachi 7750
board, and we're wondering if anyone else can give us some
tips.

First, we are able to upload S-records from Windows 
Hyperterminal to the board just fine, but we're unable
to upload even the smallest programs using Minicom or
"cat" or the mouse from Linux.  The symptoms are that
the board starts spitting a message saying 
"Error: InDev0Buff was full.".  Any ideas?

Second, we would like to try Niibe-san's gdb stub.  But
we are unable to get the "fl" command to write to the
flash memory.

We type "fl", the flash image gets moved to RAM, we upload
the S-records for a short program, the flash gets programmed,
but when we do a "md 01000000" to see the flash, it's still
all 0xff.  Any ideas?

Any help would be most appreciated.

Regards,

Mitch and Greg.
http://www.alphalink.com.au/

Re: [linuxsh-dev] Merge to standard kernel

[Greg B. <gn...@al...>]

NIIBE Yutaka wrote:
> 
> I've sent the update of SuperH potion to Alan.  All the changes in the
> CVS repository are included.
> 
> I removed some version string changes which are paradoxical (the
> case update is younger than original).
> 
> Should we use -ko option also under arch/sh and include/asm-sh?
> 
> I think that the version string won't work as everyone expects,
> so, -ko would be better choice for us.


  I agree, it's proven to be too much hassle.

  Done.  It will take effect on your next checkout.


Greg.
-- 
Fight spam http://www.caube.org.au/
If it's a choice between being a paranoid, hyper-suspicious global
village
idiot, or a gullible, mega-trusting sheep, I don't look good in mint
sauce. 
 - jd, slashdot, 11Feb2000.

[linuxsh-dev] Merge to standard kernel

[NIIBE Y. <gn...@ch...>]

I've sent the update of SuperH potion to Alan.  All the changes in the
CVS repository are included.

I removed some version string changes which are paradoxical (the
case update is younger than original).

Should we use -ko option also under arch/sh and include/asm-sh?

I think that the version string won't work as everyone expects,
so, -ko would be better choice for us.
-- 

[linuxsh-dev] patch: Multiple SCI(F)s support

[NIIBE Y. <gn...@ch...>]

Stuart Menefy wrote:
 > Index: drivers/char/sh-sci.c
 > ===================================================================
 > RCS file: /cvsroot/linuxsh/kernel/drivers/char/sh-sci.c,v
 > retrieving revision 1.9
 > diff -c -r1.9 sh-sci.c
 > *** drivers/char/sh-sci.c	2000/06/14 09:38:30	1.9
 > --- drivers/char/sh-sci.c	2000/06/15 15:43:23
 > ***************
 > *** 96,101 ****
 > --- 100,162 ----
 >   	NULL
 >   };
 >   
 > + #if defined(SCI_ONLY) || defined(SCI_AND_SCIF)
 > + static void sci_init_pins_sci(struct sci_port* port, unsigned int cflag)
 > + {
 > + }
 > + #endif
 > + 
 > + #if defined(SCIF_ONLY) || defined(SCI_AND_SCIF)
 > + #if defined(__sh3__)
 > + /* For SH7709, SH7709A, SH7729 */
 > + static void sci_init_pins_scif(struct sci_port* port, unsigned int cflag)
 > + {
 > + 	unsigned int fcr_val = 0;
 > + 
 > + 	{
 > + 		unsigned short data;
 > + 
 > + 		/* We need to set SCPCR to enable RTS/CTS */
 > + 		data = ctrl_inw(SCPCR);
 > + 		/* Clear out SCP7MD1,0, SCP6MD1,0, SCP4MD1,0*/
 > + 		ctrl_outw(data&0x0fcf, SCPCR);
 > + 	}
 > + 	if (cflag & CRTSCTS)
 > + 		fcr_val |= SCFCR_MCE;
 > + 	else {
 > + 		unsigned short data;
 > + 
 > + 		/* We need to set SCPCR to enable RTS/CTS */
 > + 		data = ctrl_inw(SCPCR);
 > + 		/* Clear out SCP7MD1,0, SCP4MD1,0,
 > + 		   Set SCP6MD1,0 = {01} (output)  */
 > + 		ctrl_outw((data&0x0fcf)|0x1000, SCPCR);
 > + 
 > + 		data = ctrl_inb(SCPDR);
 > + 		/* Set /RTS2 (bit6) = 0 */
 > + 		ctrl_outb(SCPDR, data&0xbf);

This should be:
 		ctrl_outb(data&0xbf, SCPDR);

 > + 	}
 > + 	sci_out(port, SCFCR, fcr_val);
 > + }

It works fine on SH7709A (SolutionEngine).

Please check in.  Then, let's assign new device number for it.
I think that we need CONFIG_SCI_SERIAL again.

The rationale for new device number is: some boards has same serial
chip as PC and he may want to use standard serial driver.
-- 

Re: [linuxsh-dev] binutils in CVS should be OK now

[<mj...@al...>]

>I tried the binutils on SourceForge, unfortunatly one of Niibe-san's
>patches appears to be missing:

Thanks Stuart, I've applied this patch.  Niibe-san, sorry
I forgot it.

Regards,

Mitch.
http://www.alphalink.com.au/