linuxsh-dev

[linuxsh-dev] Ptrace

[David M. <Dav...@st...>]

Hi,

Is anybody doing any work on ptrace and strace? I know that much of it has 
been implemented, but I can't seem to get gdb to debug user programs. 

I was going to start looking at this in the near future, but I don't want 
to duplicate work anybody else is doing.

Cheers!

-- 
Dave McKay 
Software Engineer STMicroelectronics
Email: dav...@st...

[linuxsh-dev] Debianized packages of GNU tool chain

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

Developers,

May I add a directory named "debian" to the top of each of GNU
tools in our CVS?  This enables us to generate binary packages
for Debian systems easily.

As you know, I have maintained Debianized packages of them at
ftp://ftp.m17n.org/pub/linux-sh/debian/.  Now I have built newer
packages whose target is 'sh-linux-gnu', and they will be
avaiable there soon.

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

[linuxsh-dev] Assorted patches for Linux kernel, and the stub.

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

NIIBE Yutaka wrote:
 > Well done.  Please check them (except the Load Memory Addresses thing)
 > in.  May I ask you to incorporate changes of sh-sci.c,h done by
 > Stuart?

I've misunderstood the situation.  The patch is by Takeshi.  I've just
checked in following patch.

2000-07-20  YAEGASHI Takeshi  <yae...@ma...>

	* sh-sci.h (PORT_IRDA, SH3_IRDA_IRQS): New definition.
	(SCI_INIT, SCI_NPORTS): Fixed for CONFIG_CPU_SUBTYPE_SH7708.

	* sh-sci.c (sci_init_pins_irda): New Function.

Index: drivers/char/sh-sci.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/char/sh-sci.c,v
retrieving revision 1.11
diff -u -r1.11 sh-sci.c
--- drivers/char/sh-sci.c	2000/07/04 09:45:19	1.11
+++ drivers/char/sh-sci.c	2000/07/20 05:30:57
@@ -62,6 +62,7 @@
 #ifndef SCI_ONLY
 static void sci_init_pins_scif(struct sci_port* port, unsigned int cflag);
 #endif
+static void sci_init_pins_irda(struct sci_port* port, unsigned int cflag);
 static void sci_disable_tx_interrupts(void *ptr);
 static void sci_enable_tx_interrupts(void *ptr);
 static void sci_disable_rx_interrupts(void *ptr);
@@ -138,6 +139,16 @@
 		/* Set /RTS2 (bit6) = 0 */
 		ctrl_outb(data&0xbf, SCPDR);
 	}
+	sci_out(port, SCFCR, fcr_val);
+}
+
+static void sci_init_pins_irda(struct sci_port* port, unsigned int cflag)
+{
+	unsigned int fcr_val = 0;
+
+	if (cflag & CRTSCTS)
+		fcr_val |= SCFCR_MCE;
+
 	sci_out(port, SCFCR, fcr_val);
 }
 
Index: drivers/char/sh-sci.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/char/sh-sci.h,v
retrieving revision 1.9
diff -u -r1.9 sh-sci.h
--- drivers/char/sh-sci.h	2000/06/22 17:52:03	1.9
+++ drivers/char/sh-sci.h	2000/07/20 05:30:57
@@ -13,6 +13,7 @@
 /* Values for sci_port->type */
 #define PORT_SCI  0
 #define PORT_SCIF 1
+#define PORT_IRDA 1		/* XXX: temporary assignment */
 
 /* Offsets into the sci_port->irqs array */
 #define SCIx_ERI_IRQ 0
@@ -22,6 +23,7 @@
 /*                     ERI, RXI, TXI,   INTC reg, INTC pos */
 #define SCI_IRQS      { 23,  24,  25 }, INTC_IPRB, 1
 #define SH3_SCIF_IRQS { 56,  57,  59 }, INTC_IPRE, 1
+#define SH3_IRDA_IRQS { 52,  53,  55 }, INTC_IPRE, 2
 #define SH4_SCIF_IRQS { 40,  41,  43 }, INTC_IPRC, 1
 
 #if defined(CONFIG_CPU_SUBTYPE_SH7708)
@@ -33,21 +35,11 @@
 # define SCSCR_INIT(port)          0x30 /* TIE=0,RIE=0,TE=1,RE=1 */
 # define SCI_ONLY
 #elif defined(CONFIG_CPU_SUBTYPE_SH7709)
-# define SCI_NPORTS 2
-# define SCI_INIT { \
-  { {}, PORT_SCI,  0xfffffe80, SCI_IRQS,      sci_init_pins_sci  }, \
-  { {}, PORT_SCIF, 0xA4000150, SH3_SCIF_IRQS, sci_init_pins_scif }  \
-}
-# define SCPCR  0xA4000116 /* 16 bit SCI and SCIF */
-# define SCPDR  0xA4000136 /* 8  bit SCI and SCIF */
-# define SCSCR_INIT(port)          0x30 /* TIE=0,RIE=0,TE=1,RE=1 */
-# define SCI_AND_SCIF
-#elif defined(CONFIG_CPU_SUBTYPE_SH7709A)
 # define SCI_NPORTS 3
 # define SCI_INIT { \
   { {}, PORT_SCI,  0xfffffe80, SCI_IRQS,        sci_init_pins_sci  }, \
-  { {}, PORT_SCIF, 0xA4000150, 7709A_SCIF_IRQS, sci_init_pins_scif }  \
-  { {}, PORT_SCIF, 0xA4000140, 7709A_IRDA_IRQS, sci_init_pins_irda }  \
+  { {}, PORT_SCIF, 0xA4000150, SH3_SCIF_IRQS, sci_init_pins_scif },   \
+  { {}, PORT_SCIF, 0xA4000140, SH3_IRDA_IRQS, sci_init_pins_irda }    \
 }
 # define SCPCR  0xA4000116 /* 16 bit SCI and SCIF */
 # define SCPDR  0xA4000136 /* 8  bit SCI and SCIF */

[linuxsh-dev] My solution for alias problem of shared pages

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

Stuart Menefy reported that we need to care some special treatment
for shared pages.  Here's my solution for that problem.

When the page is shared, we flush the relevant TLB and caches on
TLB update.  With this treatment, there's at most one TLB for that
page, and there're no cache line shared.

Comments?  It's not tested yet.  (it's committed along with other
changes)

Index: arch/sh/mm/fault.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/fault.c,v
retrieving revision 1.12
diff -u -r1.12 fault.c
--- arch/sh/mm/fault.c	2000/07/04 06:24:41	1.12
+++ arch/sh/mm/fault.c	2000/07/18 05:33:50
@@ -29,6 +29,9 @@
 
 extern void die(const char *,struct pt_regs *,long);
 static void __flush_tlb_page(struct mm_struct *mm, unsigned long page);
+#if defined(__SH4__)
+static void __flush_tlb_phys(struct mm_struct *mm, unsigned long phys);
+#endif
 
 /*
  * Ugly, ugly, but the goto's result in better assembly..
@@ -277,6 +280,19 @@
 
 	save_and_cli(flags);
 
+#if defined(__SH4__)
+	if ((vma->vm_flags & VM_SHARED)) {
+		pteval = pte_val(pte);
+		pteval &= PAGE_MASK; /* Physicall page address */
+
+		__flush_tlb_phys(vma->vm_mm, pteval);
+
+		/* It would be good we had routine which takes
+		   physical memory as argument */
+		flush_cache_page(vma, address&PAGE_MASK);
+	}
+#endif
+
 	/* Set PTEH register */
 	if (vma) {
 		pteaddr = (address & MMU_VPN_MASK) |
@@ -327,6 +343,33 @@
 	if (saved_asid != MMU_NO_ASID)
 		set_asid(saved_asid);
 }
+
+#if defined(__SH4__)
+static void __flush_tlb_phys(struct mm_struct *mm, unsigned long phys)
+{
+	int i;
+	unsigned long addr, data;
+
+	jump_to_P2();
+	for (i = 0; i < MMU_UTLB_ENTRIES; i++) {
+		addr = MMU_UTLB_DATA_ARRAY | (i<<MMU_U_ENTRY_SHIFT);
+		data = ctrl_inl(addr);
+		if ((data & MMU_UTLB_VALID) && (data&PAGE_MASK) == phys) {
+			data &= ~MMU_UTLB_VALID;
+			ctrl_outl(data, addr);
+		}
+	}
+	for (i = 0; i < MMU_ITLB_ENTRIES; i++) {
+		addr = MMU_ITLB_DATA_ARRAY | (i<<MMU_I_ENTRY_SHIFT);
+		data = ctrl_inl(addr);
+		if ((data & MMU_ITLB_VALID) && (data&PAGE_MASK) == phys) {
+			data &= ~MMU_ITLB_VALID;
+			ctrl_outl(data, addr);
+		}
+	}
+	back_to_P1();
+}
+#endif
 
 void flush_tlb_page(struct vm_area_struct *vma, unsigned long page)
 {
-- 

[linuxsh-dev] Assorted patches for Linux kernel, and the stub.

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

Mitch Davis wrote:
 > As Greg indicated in his earlier email, here are the diffs we
 > have been working on.  There's a patch for the kernel code, and
 > a patch for the stub.

Thanks for your effort.  It's great contribution.

Here're some comments:

 > x  Link script sets Load Memory Addresses so that kernel image
 >    load bypasses the cache, to avoid cache problems.

No, this is backward.  If you have any problems, please send us bug
report.  The changes like this just paper the bugs, and hide them.
It's not the solution.  Major problem is it loses performance.
Besides, I don't know the problem around cache issues, which is
solved with this change.

It seems for me that what to change is GDB stub, if needed.

 > --- kernel-orig/arch/sh/kernel/sh_bios.c	Thu Jan  1 10:00:00 1970
 > +++ kernel/arch/sh/kernel/sh_bios.c	Tue Jul 18 03:57:22 2000
 > @@ -0,0 +1,70 @@
 > +/* $Id$
 > + *
 > + *  linux/arch/sh/kernel/sh-bios.c
 > + *  C interface for trapping into the standard LinuxSH BIOS.
 > + *
 > + *  Copyright (C) 2000 Greg Banks, Mitch Davis
 > + *
 > + */

It would be good if we have license notice here (which I sometimes
forgot).  Please look arch/sh/kernel/entry.S for example.

Well done.  Please check them (except the Load Memory Addresses thing)
in.  May I ask you to incorporate changes of sh-sci.c,h done by
Stuart?  It seems that he's off-line nowadays.  I'm thinking send our
update to Linus.  I'll incorporate his other changes, if he won't.

 > This is a patch against the gdb stub version 2000-06-22.  The
 > following is a description of changes.

I'll incorporate this changes.  Thanks.
-- 

[linuxsh-dev] Assorted patches for Linux kernel, and the stub.

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

Hello,

As Greg indicated in his earlier email, here are the diffs we
have been working on.  There's a patch for the kernel code, and
a patch for the stub.

Preceding each patch is a list of changes.  The patches can
also be retrieved from here:

Kernel patch: (linux-sh-2000-07-18-gnb-mjd.diff.bz2)

  http://sourceforge.net/patch/?func=detailpatch&patch_id=100920&group_id=2682
  
Stub patch: (gdb-sh-stub-2000-06-22-gnb-mjd.diff.bz2)

  http://sourceforge.net/patch/?func=detailpatch&patch_id=100921&group_id=2682

We are posting them here for public comment.  All suggestions and
ideas are most welcome.

Regards,

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

[linuxsh-dev] LINUS Branch

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

If there's no objection (read: any specific needs and volunteer who
works for that), I think I don't maintain LINUS branch in the
repository.

The good thing having LINUS branch is we can compare the differences
between official kernel and our kernel with the repository.

The bad thing is it takes cost to maintain.  As I said, it's easier
not to import the LINUS branch, just go with HEAD branch applying the
patch from Linus.  As far as the differences are small (yes, we have
to do our best to keep the differences small, anyway), I think that we
don't have strong reason having the LINUS branch.

If people really need to compare differences, they can do locally with
standard kernel distribution.
-- 

[linuxsh-dev] Memory map for loading kernel

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

I'd like to reserve 64KB for the second storage loader (see the patch
below).  I think that Takeshi cares...

I'm thinking of following memory map:


	+------------------+  0
	|*                 |       1 page for ROM monitor use
	|                  |
	|                  |
	|                  |
	|                  |
	|                  |
	+------------------+  2MB
	|****************  |       16 page for loader use
	|                  |
	|                  |
	|                  |
	:                  :
	:                  :
	|                  |
	|                  |
	+------------------+

The boot sequence is like follows:

  (1) ROM IPL uses the first page for working area (and stack).

  (2) IPL reads MBR on disk into the memory at 2MB, and jumps to it.

  (3) The program within MBR (first stage loader) reads the second
      stage loader and boot information (kernel map, initrd map,
      keyboard translation table command line args, and such) into
      the memory around 2MB.

  (4) Control goes to the seond loader and it reads kernel images
      into the memory above (> 2MB), and jumps to it.

  (5) zImage expand itself into the memory, and jumps to it.


2000-07-11  NIIBE Yutaka  <gn...@m1...>

	* arch/sh/boot/compressed/Makefile (ZIMAGE_OFFSET): Add more
	64KB for the use of program loader which load the image from
	second storage.

Index: arch/sh/boot/compressed/Makefile
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/boot/compressed/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- arch/sh/boot/compressed/Makefile	2000/06/10 21:45:10	1.3
+++ arch/sh/boot/compressed/Makefile	2000/07/11 06:30:23
@@ -14,7 +14,7 @@
 #
 # ZIMAGE_OFFSET is the load offset of the compression loader
 #
-ZIMAGE_OFFSET = $(shell printf "0x%8x" $$[0x80000000+0x$(CONFIG_MEMORY_START)+0x200000])
+ZIMAGE_OFFSET = $(shell printf "0x%8x" $$[0x80000000+0x$(CONFIG_MEMORY_START)+0x200000+0x10000])
 
 ZLINKFLAGS = -Ttext $(ZIMAGE_OFFSET) $(ZLDFLAGS)
 
-- 

Re: [linuxsh-dev] 2.4.0-test2

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

NIIBE Yutaka wrote:
 > I'll import 2.4.0-test2 and 2.4.0-test3-pre2 this afternoon.
 > I'm sure it results conflict.

Done.

Mitch Davis wrote:
 > The LINUS branch is the "vendor" branch onto which imports
 > of the official Linux kernel go.  The merge phase (which
 > brings Linus' changes into our kernel) works by comparing
 > old-and-new tagged revisions on the LINUS branch, and applying
 > these differences to our "main" branch.  These differences
 > are then checked in, giving us the official changes.  

Thanks for your explanation.

I should have explained more clearly.  My question is:
	Who use LINUS branch?
	If it's only for merge, I don't think it worth to have it.

It takes time (for me) to resolve the conflicts.  On the other hand,
it is *not* needed to use "merge" feature of CVS.  Just apply the
patch of Linus (except the update I sent to Linus), that's enough.

Because the import process has no knowledge of our update to the
mainstream, the import after the sending update to Linus (or Alan)
always causes conflicts, provided we don't do any special things.
-- 

Re: [linuxsh-dev] 2.4.0-test2

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

NIIBE Yutaka wrote:
> 
> I'll import 2.4.0-test2 and 2.4.0-test3-pre2 this afternoon.
> I'm sure it results conflict.
> 
> I'm not sure why we need LINUS branch, BTW.  Are thare anyone using
> that stuff?

The LINUS branch is the "vendor" branch onto which imports
of the official Linux kernel go.  The merge phase (which
brings Linus' changes into our kernel) works by comparing
old-and-new tagged revisions on the LINUS branch, and applying
these differences to our "main" branch.  These differences
are then checked in, giving us the official changes.  
You may wish to revise this:

  http://linuxsh.sourceforge.net/docs/importing-kernels.php3

In short, it's necessary for importing official kernels.
I would be happy to import 2.4.0-test2 if you like.  I can
do it tonight in about 4 hours.

(I've not been doing it lately because I wanted to wait
for Linus to pull in Alan Cox's -ac line of kernels.  Now
that he's done this with test2, I'll import it).

Regards,

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

Re: [linuxsh-dev] slab poisoning

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

NIIBE Yutaka wrote:
 > But still I think that the issue I mentioned exists
 > (when packet length is odd).

No, I was wrong.  Since skb->end is aligned, there's no such off-by-one
confusion to be occurred.
-- 

[linuxsh-dev] 2.4.0-test2

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

I'll import 2.4.0-test2 and 2.4.0-test3-pre2 this afternoon.
I'm sure it results conflict.

I'm not sure why we need LINUS branch, BTW.  Are thare anyone using
that stuff?
-- 

Re: [linuxsh-dev] slab poisoning

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

Stuart Menefy wrote:
 > I've found what was causing the 'slab poisoning' problem which I reported
 > a few days ago. There is a bug in the kernel when setting the interrupt
 > mask bits in the status register when returning from an exception. This
 > can result in interrupts being re-enabled when they should not be.
[...]

Well spotted.  But still I think that the issue I mentioned exists
(when packet length is odd).

 > I'm surprised nobody else is seeing these problems. Are we the only
 > people using SH4 perhaps?

SolutionEngine SH4 is configured using it's own interrupt controller, 
so it doesn't used irq_mask.

 > One thing I did spot while doing this. The irq_imask technique of
 > interrupt masking will not work with interrupts at priority 15. Not
 > really a problem, but it might be worth adding a comment somewhere
 > before this trips somebody up.

Agreed.

Please check all of the pending patches of yours in.  I have an idea
for handling alias issue of shared page.  I'll modify the code, when
you commit.
-- 

[linuxsh-dev] help with gdb

[<ch...@li...>]

I have found that gdb for sh from CVS ,but i have no idea how to
use it! Could any me give me a hint or any document ??



Best regards,


						Chester

Re: [linuxsh-dev] slab poisoning

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

Folks

I've found what was causing the 'slab poisoning' problem which I reported
a few days ago. There is a bug in the kernel when setting the interrupt
mask bits in the status register when returning from an exception. This
can result in interrupts being re-enabled when they should not be.

The particular sequence of events which caused this in my situation was:
 - kernel is executing in the slab memory allocator free function
 - executes a spin_lock_irqsave which disables interrupts
 - takes a floating point exception
 - on return from the exception interrupts are erroneously re-enabled
 - an interrupt from the Ethernet controller occurs
 - interrupt handler calls the slab allocator to allocate a packet
 - packet which is returned is one which has been freed but not yet
   poisoned, and so fails the poison test

A patch is attached which fixes this, which I'll check this in in the
next few days if nobody objects. It also feels like it improves
overall reliability, although I've not got any data to back this up.

I'm surprised nobody else is seeing these problems. Are we the only
people using SH4 perhaps?

One thing I did spot while doing this. The irq_imask technique of
interrupt masking will not work with interrupts at priority 15. Not
really a problem, but it might be worth adding a comment somewhere
before this trips somebody up.

Stuart

Re: [linuxsh-dev] Caches question

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

Stuart Menefy wrote:
 > That I'll teach me to copy code without fully understanding it! On further
 > investigation I think it is needed, but I'd be delighted to be proved
 > wrong.

Well, I'm really confusing about the code.  I think that the code sometimes
works, but totally wrong.

Let's clarify things and discuss.

    (1) When do we need to fixup?
    (2) How can we find corresponding mapping?
    (3) How can we fix?

Let's discuss one by one.

(1) When do we need to fixup?

When there is shared mapping which causes the alias (synonym).  We
handle it at the TLB miss handling, finding the page with flags
VM_WRITE and VM_SHARED.

In this case, there is possibility that the page is shared among
different virtual mappings (which may or may not the map of the same
process) and page causes aliases (same physical memory but different
cache lines).


(2) How can we find corresponding mapping which shares the physical page?

# Here is, my confusing point.  I don't think the sun4c implementation
# handles the cases correctly.

Suppose we have virtual memory mapping (say, VMA) of the process.  In
this case we scan VMA through "vm_next_share" link.  We need to tangle
the link only if VMA->vm_file !=0 (??is this correct??, anonymous
page?).

Following the link "vm_next_share", we scan through all the mapping of
the file, and find the coresspoinding mapping which shares same physical
memory.  We need to check vm_pgoff to find matching mapping.


(3) How can we fix?

There're some alternatives.
    (a) Flushing cache for the page and TLB which may point that physical
        page.  Then set the flag of matching mapping VM_WRITE|VM_SHARED
        even if it was not set, so that using this map will cause TLB miss, 
        and come this fixup routine.
	No PTE handling is required.

    (b) Make each PTEs uncache-able so that we don't cache any data.

Comments?  Thoughts?
-- 

[linuxsh-dev] slab poisoning

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

Stuart Menefy wrote:
 > A big of digging appears to show that an Ethernet frame is being written
 > into a slab of memory which is on the free list. I can't believe this
 > is a generic kernel/driver/mm problem, otherwise it would have been
 > fixed by now, but equally I can't see anything SuperH specific about this
 > either.
 > 
 > Any ideas anyone?

I think that there's a bug at stnic_block_input.  Consider the case
length is odd number.  The variable length is incremented by one.  The
loop handles HALF (2-byte) at a time.  This could be overflow the SKB
buffer by one-byte.  Just a one byte, but the field at skb->end is
used for skb_datarefp macro.  I guess this causes bad effect on
resource calculation of SKB.
-- 

Re: [linuxsh-dev] slab poisoning

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

--- Jaswinder Singh <jas...@ya...> wrote:
> 
> --- Stuart Menefy <Stu...@st...> wrote:
> > Folks
> 
> hello,
> 
> > 
> > I've been chasing a problem for a few hours now,
> and
> > I was just wondering if
> > anyone else has seen it.
> > 
> 
> i have not seen this problem , but i also face many
> problems during ftp , this is because i am using
> RAMDISK , and i dont put all the file required by
> the
> ftp at runtime . please check this out in your case
> ,
> which files are required by "open" function . may be
> i
> am wrong .
> 
> > When using the ST-NIC Ethernet interface on the
> 7750
> > Solution Engine,
> > and transferring a fairly large (~ 0.5Mb) using
> FTP,
> > I start getting the
> > error message:
> >   kmem_alloc: Bad poison (name=size-2048)
> > 
> > A big of digging appears to show that an Ethernet
> > frame is being written
> > into a slab of memory which is on the free list. I
> > can't believe this
> > is a generic kernel/driver/mm problem, otherwise
> it
> > would have been
> > fixed by now, but equally I can't see anything
> > SuperH specific about this
> > either.
> > 
> 
> debug by "SLAB_DEBUG_SUPPORT" , may be it will help
> u
> to find the problem .

i also want to tell u that slab is depending on cache
& u play with cache , so if possible use the old code
of cache & check that r u facing the same problem in
old code or not. may be i am wrong :(
 
Regards,
 
Jaswinder.
 


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

Re: [linuxsh-dev] slab poisoning

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

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

hello,

> 
> I've been chasing a problem for a few hours now, and
> I was just wondering if
> anyone else has seen it.
> 

i have not seen this problem , but i also face many
problems during ftp , this is because i am using
RAMDISK , and i dont put all the file required by the
ftp at runtime . please check this out in your case ,
which files are required by "open" function . may be i
am wrong .

> When using the ST-NIC Ethernet interface on the 7750
> Solution Engine,
> and transferring a fairly large (~ 0.5Mb) using FTP,
> I start getting the
> error message:
>   kmem_alloc: Bad poison (name=size-2048)
> 
> A big of digging appears to show that an Ethernet
> frame is being written
> into a slab of memory which is on the free list. I
> can't believe this
> is a generic kernel/driver/mm problem, otherwise it
> would have been
> fixed by now, but equally I can't see anything
> SuperH specific about this
> either.
> 

debug by "SLAB_DEBUG_SUPPORT" , may be it will help u
to find the problem .

Regards,

Jaswinder.

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

[linuxsh-dev] slab poisoning

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

Folks

I've been chasing a problem for a few hours now, and I was just wondering if
anyone else has seen it.

When using the ST-NIC Ethernet interface on the 7750 Solution Engine,
and transferring a fairly large (~ 0.5Mb) using FTP, I start getting the
error message:
  kmem_alloc: Bad poison (name=size-2048)

A big of digging appears to show that an Ethernet frame is being written
into a slab of memory which is on the free list. I can't believe this
is a generic kernel/driver/mm problem, otherwise it would have been
fixed by now, but equally I can't see anything SuperH specific about this
either.

Any ideas anyone?

Stuart

Re: [linuxsh-dev] Caches question

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

On Jun 24, 11:01am, gn...@ch... wrote:
> Subject: Re: [linuxsh-dev] Caches question
> 
> 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.

That's what I was hoping, I wasn't sure. If that's the case, good!

Stuart

Re: [linuxsh-dev] Caches question

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

Niibe-san

That I'll teach me to copy code without fully understanding it! On further
investigation I think it is needed, but I'd be delighted to be proved
wrong.

As I see it, there are two reasons for doing this loop:

 - to flush the cache and TLB of any aliases which may already have been
   read before the page was shared. I was hoping the generic code
   would already have done this, but after a few experiments, it doesn't
   appear to be doing so. I guess at the point the mmap() is performed,
   the PTE's are not modified, so the flush is not required.

 - to mark the pte's of any pages which have already been allocated
   as uncacheable. Your're right, at the moment because the TLB entry will
   have been flushed, we will always come here again as part of the TLB
   miss exception, and so we don't need to modify the pte's here.
   At some point in the future we will probably want to try and optimise
   the TLB miss code for the common case of the pte already being set up,
   at which time this code or something similar may be required.

If this is right, then the loop is only required when the sharing is
first set up, so should be optimisable, but I think it is required.

Stuart

On Jun 24, 10:56am, gn...@ch... wrote:
> Subject: Re: [linuxsh-dev] Caches question
> 
> 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 mailing list
> lin...@li...
> http://lists.sourceforge.net/mailman/listinfo/linuxsh-dev
>-- End of excerpt from gn...@ch...

re [linuxsh-dev] Ramdisk

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

Hello,

Jaswinder, I've tried  your ram disk, but the situation is the same, same
error.
Maybe I'm wrong, but I think, I build correct the ram disk ( with 2 MB works
it fine) 
I'm using Ludovic's loader. I've forgot to change the old ram disk size = 4
MB in this bootloader, and I've used a 2 MB ram disk, which is working
fine....So root-fs-image = 4 MB doesn't and root-fs-image = 2 MB works fine,
all these things with bootloader parameters for 4 MB disk and rd_size = 8192
(8MB in rd.c file) 
I don't know....
that's funny...when I removed "sock_init" from init/main.c also ram disk 4
MB works fine...what's happening here ???

grateful for any help,
Pawel

re: [linuxsh-dev] Ramdisk

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

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

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
> 

This shows problem is during loading the RAMDISK.

> 
> After Your mail, I've increased size rd_size to
> 8192, but it doesn't
> help...

If you are using 4MB or less then 4MB you dont need to
change it.

>and I'm still using 2 MB RAM disk...
> 

It means , your kernel is working fine with 2 MB
RAMDISK.


> maybe has somebody tried to hard code kernel options
> (ramdisk_size,
> ramdisk_start, mem etc.) ??
> 	

print ramdisk_size before the process of loading
RAMDISK.

>  should I also modify variables argv_init, envp_init
> in init/main.c ? 
>  or it is all a wrong way to solve this problem?
> 

No , dont change it right now .


I am sending compressed 4 MB RAMDISK , add the elf
header & load it as you normally do .

and show the output of the kernel .

Regards,

Jaswinder.


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

[linuxsh-dev] Re: Caches question

[kaz K. <kk...@rr...>]

Stuart Menefy <Stu...@st...> wrote:
> 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.

If this exception means the MIPS virtual coherency exception, it can
not detect the cache alias in chips with the primary cache only, like
R4000PC. Perhaps SH-4 is corresponding to such chip, though I don't
know about the newer MIPS chips.

	kaz