Re: CVS Update@linux-mips.org: linux

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Thu, Jul 21, 2005 at 04:33:53PM +0100, ths@linux-mips.org wrote:

> Modified files:
> 	arch/mips/kernel: binfmt_elfo32.c 
> 	include/asm-mips: elf.h 
> 
> Log message:
> 	Fix ELF defines: EF_* is a field, E_* a distinct flag therein.

Remarkably bad idea after the old definitions are already being used since
over a decade.

Btw, I don't recall approving that patch ...

  Ralf

Going over 512M of memory

[Alex Gonzalez]

Hi,

Our target experienced a kernel panic at startup when trying to access
memory above 512MB.

Reading the list archives I found this thread with a proposed patch:

http://www.linux-mips.org/archives/linux-mips/2005-02/msg00115.html

After applying the patch our target boots OK and appears to be able to
access the whole memory range without problems.

Any idea why this patch didn't make it to the repository? Is it safe?

Thanks,
Alex

Realtime preemption patches

[Alex Gonzalez]

Hi,

I am not having much success trying to apply Ingo's realtime patches (
http://people.redhat.com/mingo/realtime-preempt/) to a 2.6.12-rc3 linux-mips kernel.

Has anybody succeeded in doing so? Is there an intermediate patch I'm missing available?

Alex

Re: CVS Update@linux-mips.org: linux

[Thiemo Seufer]

Ralf Baechle wrote:
> On Thu, Jul 21, 2005 at 04:33:53PM +0100, ths@linux-mips.org wrote:
> 
> > Modified files:
> > 	arch/mips/kernel: binfmt_elfo32.c 
> > 	include/asm-mips: elf.h 
> > 
> > Log message:
> > 	Fix ELF defines: EF_* is a field, E_* a distinct flag therein.
> 
> Remarkably bad idea after the old definitions are already being used since
> over a decade.

Well, kernel headers are less widely used than others, and everywhere
else it is E_*. Since
 - kernel headers in general aren't meant as an interface for userland,
 - the definition is inconsistent to the userland one,
 - the in-kernel use seems to be limited to the ELF binary object
   loader and probably third party modules loaders
I found moving to a consistent definition to be more useful than
keeping the old inconsistent one.


Thiemo

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Fri, Jul 22, 2005 at 02:10:30PM +0200, Thiemo Seufer wrote:
> Date:	Fri, 22 Jul 2005 14:10:30 +0200
> To:	Ralf Baechle <ralf@linux-mips.org>
> Cc:	linux-mips@linux-mips.org
> Subject: Re: CVS Update@linux-mips.org: linux
> Content-Type: text/plain; charset=us-ascii
> From:	Thiemo Seufer <ths@networkno.de>
> 
> Ralf Baechle wrote:
> > On Thu, Jul 21, 2005 at 04:33:53PM +0100, ths@linux-mips.org wrote:
> > 
> > > Modified files:
> > > 	arch/mips/kernel: binfmt_elfo32.c 
> > > 	include/asm-mips: elf.h 
> > > 
> > > Log message:
> > > 	Fix ELF defines: EF_* is a field, E_* a distinct flag therein.
> > 
> > Remarkably bad idea after the old definitions are already being used since
> > over a decade.
> 
> Well, kernel headers are less widely used than others, and everywhere
> else it is E_*. Since
>  - kernel headers in general aren't meant as an interface for userland,
>  - the definition is inconsistent to the userland one,

Glibc is the only thing elf.h that defines the E_* names at all and
explicitly says "don't use".

>  - the in-kernel use seems to be limited to the ELF binary object
>    loader and probably third party modules loaders
> I found moving to a consistent definition to be more useful than
> keeping the old inconsistent one.

I think you're confusing binutils's internal definitions with the use
everywhere else.

Mind pulling that patch?

  Ralf

Re: Going over 512M of memory

[Ralf Baechle]

On Fri, Jul 22, 2005 at 10:04:47AM +0100, Alex Gonzalez wrote:

> Our target experienced a kernel panic at startup when trying to access
> memory above 512MB.
> 
> Reading the list archives I found this thread with a proposed patch:
> 
> http://www.linux-mips.org/archives/linux-mips/2005-02/msg00115.html
> 
> After applying the patch our target boots OK and appears to be able to
> access the whole memory range without problems.
> 
> Any idea why this patch didn't make it to the repository? Is it safe?

It is - but according to Ibrahim's posting that you're pointing to it
didn't solve his problem.

What CPU are you using, btw?

  Ralf

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Fri, 22 Jul 2005, Ralf Baechle wrote:

> >  - the in-kernel use seems to be limited to the ELF binary object
> >    loader and probably third party modules loaders
> > I found moving to a consistent definition to be more useful than
> > keeping the old inconsistent one.
> 
> I think you're confusing binutils's internal definitions with the use
> everywhere else.

 In particular when in doubt please refer to ELF standards which state 
"EF_" is the prefix for processor-specific flags in "e_flags" in the ELF 
file header; similarly with "EM_" for "e_machine" and "ET_" for "e_type" 
-- you should see the pattern.  There is no mention of the "E_" prefix in 
the standards.

  Maciej

Re: Going over 512M of memory

[Alex Gonzalez]

It's a RM9020.

Quoting Ibrahim's,

"With a slightly extended patch it actually works. But afterwards
I get a lot of Illegal instructions and Segmentation faults, where
there shouldn't be any. Below is the patch I used."

And after you post an improved patch, he says,

"I presume CKSEG is CKSEG0 in the above patch. With that it works
about the same as before. So do you have any clue what the problem
behind all that really is? Furthermore I still have all those
"Illegal instruction" and "Segmentation fault" messages that
shouldn't be there."

The illegal instructions and segmentation faults turned to be the cpu_has_64bit_gp_regs setting. So I presume it worked for him.

In our case, it seems to work completely OK. I am running a complete memory test over the whole 1G to be completely sure (with memtester), and I'll report the result back.

Thanks,
Alex


On Fri, 2005-07-22 at 14:14, Ralf Baechle wrote:
> On Fri, Jul 22, 2005 at 10:04:47AM +0100, Alex Gonzalez wrote:
> 
> > Our target experienced a kernel panic at startup when trying to access
> > memory above 512MB.
> > 
> > Reading the list archives I found this thread with a proposed patch:
> > 
> > http://www.linux-mips.org/archives/linux-mips/2005-02/msg00115.html
> > 
> > After applying the patch our target boots OK and appears to be able to
> > access the whole memory range without problems.
> > 
> > Any idea why this patch didn't make it to the repository? Is it safe?
> 
> It is - but according to Ibrahim's posting that you're pointing to it
> didn't solve his problem.
> 
> What CPU are you using, btw?
> 
>   Ralf
-- 

Alex Gonzalez
Packet Vision Limited
Unit I4, Reading Enterprise Hub
Earley Gate, Whiteknights Road
Reading, Berkshire, UK
RG6 6AU
                                                                
T. +44 (0) 1189 357070
F. +44 (0) 1189 357330
                                                                
www.packetvision.com
===================================================== 

Re: CVS Update@linux-mips.org: linux

[Ralf Baechle]

On Fri, Jul 22, 2005 at 02:24:48PM +0100, Maciej W. Rozycki wrote:

> > >  - the in-kernel use seems to be limited to the ELF binary object
> > >    loader and probably third party modules loaders
> > > I found moving to a consistent definition to be more useful than
> > > keeping the old inconsistent one.
> > 
> > I think you're confusing binutils's internal definitions with the use
> > everywhere else.
> 
>  In particular when in doubt please refer to ELF standards which state 
> "EF_" is the prefix for processor-specific flags in "e_flags" in the ELF 
> file header; similarly with "EM_" for "e_machine" and "ET_" for "e_type" 
> -- you should see the pattern.  There is no mention of the "E_" prefix in 
> the standards.

Which makes me wonder why glibc has the E_ definitions.  Other operating
systems that I looked up don't.

  Ralf

Re: CVS Update@linux-mips.org: linux

[Thiemo Seufer]

Ralf Baechle wrote:
> On Fri, Jul 22, 2005 at 02:10:30PM +0200, Thiemo Seufer wrote:
> > Date:	Fri, 22 Jul 2005 14:10:30 +0200
> > To:	Ralf Baechle <ralf@linux-mips.org>
> > Cc:	linux-mips@linux-mips.org
> > Subject: Re: CVS Update@linux-mips.org: linux
> > Content-Type: text/plain; charset=us-ascii
> > From:	Thiemo Seufer <ths@networkno.de>
> > 
> > Ralf Baechle wrote:
> > > On Thu, Jul 21, 2005 at 04:33:53PM +0100, ths@linux-mips.org wrote:
> > > 
> > > > Modified files:
> > > > 	arch/mips/kernel: binfmt_elfo32.c 
> > > > 	include/asm-mips: elf.h 
> > > > 
> > > > Log message:
> > > > 	Fix ELF defines: EF_* is a field, E_* a distinct flag therein.
> > > 
> > > Remarkably bad idea after the old definitions are already being used since
> > > over a decade.
> > 
> > Well, kernel headers are less widely used than others, and everywhere
> > else it is E_*. Since
> >  - kernel headers in general aren't meant as an interface for userland,
> >  - the definition is inconsistent to the userland one,
> 
> Glibc is the only thing elf.h that defines the E_* names at all and
> explicitly says "don't use".

It looks like things are worse than just different naming:

Glibc prefers:
#define EF_MIPS_ARCH_1      0x00000000  /* -mips1 code.  */
#define EF_MIPS_ARCH_2      0x10000000  /* -mips2 code.  */
#define EF_MIPS_ARCH_3      0x20000000  /* -mips3 code.  */
#define EF_MIPS_ARCH_4      0x30000000  /* -mips4 code.  */
#define EF_MIPS_ARCH_5      0x40000000  /* -mips5 code.  */
#define EF_MIPS_ARCH_32     0x60000000  /* MIPS32 code.  */
#define EF_MIPS_ARCH_64     0x70000000  /* MIPS64 code.  */

and knows also but depreciates:
#define E_MIPS_ARCH_1     0x00000000    /* -mips1 code.  */
#define E_MIPS_ARCH_2     0x10000000    /* -mips2 code.  */
#define E_MIPS_ARCH_3     0x20000000    /* -mips3 code.  */
#define E_MIPS_ARCH_4     0x30000000    /* -mips4 code.  */
#define E_MIPS_ARCH_5     0x40000000    /* -mips5 code.  */
#define E_MIPS_ARCH_32    0x60000000    /* MIPS32 code.  */
#define E_MIPS_ARCH_64    0x70000000    /* MIPS64 code.  */

Gcc/binutils actually create:
#define E_MIPS_ARCH_1           0x00000000
#define E_MIPS_ARCH_2           0x10000000
#define E_MIPS_ARCH_3           0x20000000
#define E_MIPS_ARCH_4           0x30000000
#define E_MIPS_ARCH_5           0x40000000
#define E_MIPS_ARCH_32          0x50000000
#define E_MIPS_ARCH_64          0x60000000
#define E_MIPS_ARCH_32R2        0x70000000
#define E_MIPS_ARCH_64R2        0x80000000

The kernel has (had):
#define EF_MIPS_ARCH_1	0x00000000      /* -mips1 code.  */
#define EF_MIPS_ARCH_2	0x10000000      /* -mips2 code.  */
#define EF_MIPS_ARCH_3	0x20000000      /* -mips3 code.  */
#define EF_MIPS_ARCH_4	0x30000000      /* -mips4 code.  */
#define EF_MIPS_ARCH_5	0x40000000      /* -mips5 code.  */
#define EF_MIPS_ARCH_32	0x50000000      /* MIPS32 code.  */
#define EF_MIPS_ARCH_64	0x60000000      /* MIPS64 code.  */
#define EF_MIPS_ARCH_32R2     0x70000000	/* MIPS32 R2 code.  */
#define EF_MIPS_ARCH_64R2     0x80000000	/* MIPS64 R2 code.  */

so glibc misinterprets E(F)_MIPS_ARCH_{32,64} as used by the toolchain.

> >  - the in-kernel use seems to be limited to the ELF binary object
> >    loader and probably third party modules loaders
> > I found moving to a consistent definition to be more useful than
> > keeping the old inconsistent one.
> 
> I think you're confusing binutils's internal definitions with the use
> everywhere else.
> 
> Mind pulling that patch?

I would prefer to have the same consistent set of names for all users.

Maciej made the point that the EF_ prefix is common for ELF header flag
defines, this suggests to standardize on the defines the kernels had
previously. This might break glibc's ld.so for third party toolchains
which followed the glibc definitions (if they actually exist).

Comments?


Thiemo

Re: CVS Update@linux-mips.org: linux

[Thiemo Seufer]

Ralf Baechle wrote:
> On Fri, Jul 22, 2005 at 02:24:48PM +0100, Maciej W. Rozycki wrote:
> 
> > > >  - the in-kernel use seems to be limited to the ELF binary object
> > > >    loader and probably third party modules loaders
> > > > I found moving to a consistent definition to be more useful than
> > > > keeping the old inconsistent one.
> > > 
> > > I think you're confusing binutils's internal definitions with the use
> > > everywhere else.
> > 
> >  In particular when in doubt please refer to ELF standards which state 
> > "EF_" is the prefix for processor-specific flags in "e_flags" in the ELF 
> > file header; similarly with "EM_" for "e_machine" and "ET_" for "e_type" 
> > -- you should see the pattern.  There is no mention of the "E_" prefix in 
> > the standards.
> 
> Which makes me wonder why glibc has the E_ definitions.  Other operating
> systems that I looked up don't.

The MIPS ELF ABI supplement mandates those bits to be zero (for MIPS I),
consequentially it doesn't need to specify names for them.


Thiemo

Re: Going over 512M of memory

[Rojhalat Ibrahim]

Hi,

I am not sure what patch you are actually talking about.
In the mentioned thread there were several. Did you only apply
the last one or all of them, i.e. did you also apply
the patches that keep flushing the caches?
Because those are really only a workaround and not a
solution to the root cause of the problem.

Rojhalat Ibrahim


Alex Gonzalez wrote:
> It's a RM9020.
> 
> Quoting Ibrahim's,
> 
> "With a slightly extended patch it actually works. But afterwards
> I get a lot of Illegal instructions and Segmentation faults, where
> there shouldn't be any. Below is the patch I used."
> 
> And after you post an improved patch, he says,
> 
> "I presume CKSEG is CKSEG0 in the above patch. With that it works
> about the same as before. So do you have any clue what the problem
> behind all that really is? Furthermore I still have all those
> "Illegal instruction" and "Segmentation fault" messages that
> shouldn't be there."
> 
> The illegal instructions and segmentation faults turned to be the cpu_has_64bit_gp_regs setting. So I presume it worked for him.
> 
> In our case, it seems to work completely OK. I am running a complete memory test over the whole 1G to be completely sure (with memtester), and I'll report the result back.
> 
> Thanks,
> Alex
> 
> 
> On Fri, 2005-07-22 at 14:14, Ralf Baechle wrote:
> 
>>On Fri, Jul 22, 2005 at 10:04:47AM +0100, Alex Gonzalez wrote:
>>
>>
>>>Our target experienced a kernel panic at startup when trying to access
>>>memory above 512MB.
>>>
>>>Reading the list archives I found this thread with a proposed patch:
>>>
>>>http://www.linux-mips.org/archives/linux-mips/2005-02/msg00115.html
>>>
>>>After applying the patch our target boots OK and appears to be able to
>>>access the whole memory range without problems.
>>>
>>>Any idea why this patch didn't make it to the repository? Is it safe?
>>
>>It is - but according to Ibrahim's posting that you're pointing to it
>>didn't solve his problem.
>>
>>What CPU are you using, btw?
>>
>>  Ralf

Re: Going over 512M of memory

[Alex Gonzalez]

The following patch works for me (Note that it's cut and pasted from the
thread so the line numbers do not correspond to current versions of the
file)

Index: arch/mips/mm/c-r4k.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v
retrieving revision 1.101
diff -u -r1.101 c-r4k.c
--- arch/mips/mm/c-r4k.c 7 Feb 2005 21:53:39 -0000 1.101
+++ arch/mips/mm/c-r4k.c 8 Feb 2005 00:18:17 -0000
@@ -566,9 +566,21 @@
if (!cpu_has_ic_fills_f_dc) {
unsigned long addr = (unsigned long) page_address(page);
- r4k_blast_dcache_page(addr);
- if (!cpu_icache_snoops_remote_store)
- r4k_blast_scache_page(addr);
+
+ if (addr)
+ r4k_blast_dcache_page(addr);
+ else
+ r4k_blast_dcache();
+
+ if (!cpu_icache_snoops_remote_store) {
+ if (addr)
+ r4k_blast_scache_page(addr);
+ else {
+ addr = page_to_pfn(page) << PAGE_SHIFT;
+ addr = CKSEG0 + (addr & ~((1UL << 24) - 1));
+ r4k_blast_scache_page_indexed(addr);
+ }
+ }
ClearPageDcacheDirty(page);
}

On Mon, 2005-07-25 at 08:43, Rojhalat Ibrahim wrote:
> Hi,
> 
> I am not sure what patch you are actually talking about.
> In the mentioned thread there were several. Did you only apply
> the last one or all of them, i.e. did you also apply
> the patches that keep flushing the caches?
> Because those are really only a workaround and not a
> solution to the root cause of the problem.
> 
> Rojhalat Ibrahim
> 
> 
> Alex Gonzalez wrote:
> > It's a RM9020.
> > 
> > Quoting Ibrahim's,
> > 
> > "With a slightly extended patch it actually works. But afterwards
> > I get a lot of Illegal instructions and Segmentation faults, where
> > there shouldn't be any. Below is the patch I used."
> > 
> > And after you post an improved patch, he says,
> > 
> > "I presume CKSEG is CKSEG0 in the above patch. With that it works
> > about the same as before. So do you have any clue what the problem
> > behind all that really is? Furthermore I still have all those
> > "Illegal instruction" and "Segmentation fault" messages that
> > shouldn't be there."
> > 
> > The illegal instructions and segmentation faults turned to be the cpu_has_64bit_gp_regs setting. So I presume it worked for him.
> > 
> > In our case, it seems to work completely OK. I am running a complete memory test over the whole 1G to be completely sure (with memtester), and I'll report the result back.
> > 
> > Thanks,
> > Alex
> > 
> > 
> > On Fri, 2005-07-22 at 14:14, Ralf Baechle wrote:
> > 
> >>On Fri, Jul 22, 2005 at 10:04:47AM +0100, Alex Gonzalez wrote:
> >>
> >>
> >>>Our target experienced a kernel panic at startup when trying to access
> >>>memory above 512MB.
> >>>
> >>>Reading the list archives I found this thread with a proposed patch:
> >>>
> >>>http://www.linux-mips.org/archives/linux-mips/2005-02/msg00115.html
> >>>
> >>>After applying the patch our target boots OK and appears to be able to
> >>>access the whole memory range without problems.
> >>>
> >>>Any idea why this patch didn't make it to the repository? Is it safe?
> >>
> >>It is - but according to Ibrahim's posting that you're pointing to it
> >>didn't solve his problem.
> >>
> >>What CPU are you using, btw?
> >>
> >>  Ralf
> 

Re: Going over 512M of memory

[Rojhalat Ibrahim]

Right. This is what I meant. That patch works around the
case when addr == 0, which should actually never happen.
IMHO the root cause is to be found in the titan_ge ethernet
driver. The XDMA descriptors contain only 29 address bits,
which corresponds to a memory segment with a size of 512MB.
The upper 11 bits of the 40 bit physical address are fixed
for all descriptors. That means that all buffers for DMA
transfers from and to the ethernet MACs have to be within
the same 512MB memory segment, in this case the lowest 512MB.
When you have more than 512MB of memory in your system those
buffers will ever so often not be in the right memory segment.
That's when stuff probably starts to go wrong.

Rojhalat Ibrahim


Alex Gonzalez wrote:
> The following patch works for me (Note that it's cut and pasted from the
> thread so the line numbers do not correspond to current versions of the
> file)
> 
> Index: arch/mips/mm/c-r4k.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/mm/c-r4k.c,v
> retrieving revision 1.101
> diff -u -r1.101 c-r4k.c
> --- arch/mips/mm/c-r4k.c 7 Feb 2005 21:53:39 -0000 1.101
> +++ arch/mips/mm/c-r4k.c 8 Feb 2005 00:18:17 -0000
> @@ -566,9 +566,21 @@
> if (!cpu_has_ic_fills_f_dc) {
> unsigned long addr = (unsigned long) page_address(page);
> - r4k_blast_dcache_page(addr);
> - if (!cpu_icache_snoops_remote_store)
> - r4k_blast_scache_page(addr);
> +
> + if (addr)
> + r4k_blast_dcache_page(addr);
> + else
> + r4k_blast_dcache();
> +
> + if (!cpu_icache_snoops_remote_store) {
> + if (addr)
> + r4k_blast_scache_page(addr);
> + else {
> + addr = page_to_pfn(page) << PAGE_SHIFT;
> + addr = CKSEG0 + (addr & ~((1UL << 24) - 1));
> + r4k_blast_scache_page_indexed(addr);
> + }
> + }
> ClearPageDcacheDirty(page);
> }
> 
> On Mon, 2005-07-25 at 08:43, Rojhalat Ibrahim wrote:
> 
>>Hi,
>>
>>I am not sure what patch you are actually talking about.
>>In the mentioned thread there were several. Did you only apply
>>the last one or all of them, i.e. did you also apply
>>the patches that keep flushing the caches?
>>Because those are really only a workaround and not a
>>solution to the root cause of the problem.
>>
>>Rojhalat Ibrahim
>>
>>
>>Alex Gonzalez wrote:
>>
>>>It's a RM9020.
>>>
>>>Quoting Ibrahim's,
>>>
>>>"With a slightly extended patch it actually works. But afterwards
>>>I get a lot of Illegal instructions and Segmentation faults, where
>>>there shouldn't be any. Below is the patch I used."
>>>
>>>And after you post an improved patch, he says,
>>>
>>>"I presume CKSEG is CKSEG0 in the above patch. With that it works
>>>about the same as before. So do you have any clue what the problem
>>>behind all that really is? Furthermore I still have all those
>>>"Illegal instruction" and "Segmentation fault" messages that
>>>shouldn't be there."
>>>
>>>The illegal instructions and segmentation faults turned to be the cpu_has_64bit_gp_regs setting. So I presume it worked for him.
>>>
>>>In our case, it seems to work completely OK. I am running a complete memory test over the whole 1G to be completely sure (with memtester), and I'll report the result back.
>>>
>>>Thanks,
>>>Alex
>>>
>>>
>>>On Fri, 2005-07-22 at 14:14, Ralf Baechle wrote:
>>>
>>>
>>>>On Fri, Jul 22, 2005 at 10:04:47AM +0100, Alex Gonzalez wrote:
>>>>
>>>>
>>>>
>>>>>Our target experienced a kernel panic at startup when trying to access
>>>>>memory above 512MB.
>>>>>
>>>>>Reading the list archives I found this thread with a proposed patch:
>>>>>
>>>>>http://www.linux-mips.org/archives/linux-mips/2005-02/msg00115.html
>>>>>
>>>>>After applying the patch our target boots OK and appears to be able to
>>>>>access the whole memory range without problems.
>>>>>
>>>>>Any idea why this patch didn't make it to the repository? Is it safe?
>>>>
>>>>It is - but according to Ibrahim's posting that you're pointing to it
>>>>didn't solve his problem.
>>>>
>>>>What CPU are you using, btw?
>>>>
>>>> Ralf
>>
> 
> 
> 
> 

Re: CVS Update@linux-mips.org: linux

[Maciej W. Rozycki]

On Fri, 22 Jul 2005, Ralf Baechle wrote:

> Which makes me wonder why glibc has the E_ definitions.  Other operating
> systems that I looked up don't.

 Well, we can scan old change logs and then throw darts at a likeness of 
the offender. ;-)  Oh -- and we could ask the person, too.

  Maciej