* Re: Cache aliasing issues using 4K pages.
From: Thiemo Seufer @ 2008-01-15 11:57 UTC (permalink / raw)
To: Luc Perneel; +Cc: linux-mips
In-Reply-To: <1a18fe6d0801142250h7ce58675i2bce7cb2e2db2669@mail.gmail.com>
Luc Perneel wrote:
> On Jan 15, 2008 2:58 AM, Thiemo Seufer <ths@networkno.de> wrote:
>
> > The Engineer wrote:
> > > We are working with a 2.6.12 kernel on a dual-core mips architecture.
> > > In this dual-core system, one core is running the linux kernel and the
> > > other is used for some real-time handling (not directly controlled by
> > > Linux)
> > > We had different stability issues, which could be pinpointed to be
> > > related with cache aliasing problems.
> > > Cache aliasing happens when the same physical memory can be cached
> > > twice as it is accessed by two different virtual addresses.
> > > Indeed, for the index to select the correct cache line the virtual
> > > address is used. If some bits of the virtual page address are used in
> > > the cache index, aliasing can occur.
> > >
> > >
> > > As there is no hardware solution in the mips to recover from this
> > > (which would provide some cache coherency, even for one core), the
> > > only intrinsic safe solution is to enlarge the page size, so that
> > > cache indexing is only done by the offset address in the page (thus
> > > the physical part of the address).
> > > Another solution is to flush the cache if a page is being remapped to
> > > an aliased address (but in our case linux does not has control on the
> > > second core, which can cause issues with shared data between both
> > > cores).
> > > Currently the second solution is used in the kernel, but we found
> > > different issues with it (for instance: we had to merge more recent
> > > mips kernels, to get a reliable copy-on-write behaviour after
> > > forks...).
> > >
> > > Therefore some questions:
> > > - Are there still some known issues with cache aliasing in the MIPS
> > kernel?
> > > - Are there known issues when using 16KB pages (8KB pages seems not be
> > > possible due to tlb issues).
> >
> > With recent kernels and toolchains 16k pages work ok IME. With a 2.6.12
> > kernel however you'll have to backport a serious amount of bugfixes
> > before 16k pages can work. Upgrading the kernel is probably less work.
> >
> > Thiemo
> >
> Thanks for the info, any idea from which kernel this works ok?
I believe the linux-2.6.22-stable branch from www.linux-mips.org is the
best version to use. I don't recall if the earlier branches got all the
necessary fixes.
Thiemo
^ permalink raw reply
* Re: Tester with IP27/IP30 needed
From: Florian Lohoff @ 2008-01-15 11:27 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips, debian-mips
In-Reply-To: <20080115112420.GA7347@alpha.franken.de>
[-- Attachment #1: Type: text/plain, Size: 997 bytes --]
On Tue, Jan 15, 2008 at 12:24:20PM +0100, Thomas Bogendoerfer wrote:
> Hi,
>
> we are facing a strange problem with lenny/sid chroots on IP28. The
> machine locks up after issuing a few ls/ps commands in a chroot
> bash. This only happens with a lenny/sid chroot, but not with etch.
> The major difference is probably the updare to glibc2.7. Since
> IP28 isn't really a nice R10k machine, it would be good, if someone
> with a working IP27/IP30 could try a lenny/sid chroot and tell us,
> if it's working/not working.
Simple testcase for me is:
/chroots/chroot-sid/lib/ld.so.1 --library-path /chroots/chroot-sid/lib /bin/bash
than the machine locks up hard ... This is with
Linux ip28 2.6.24-rc7-g0f154c48-dirty #38 Fri Jan 11 17:03:25 CET 2008 mips64 GNU/Linux
Flo
--
Florian Lohoff flo@rfc822.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Tester with IP27/IP30 needed
From: Thomas Bogendoerfer @ 2008-01-15 11:24 UTC (permalink / raw)
To: linux-mips
Hi,
we are facing a strange problem with lenny/sid chroots on IP28. The
machine locks up after issuing a few ls/ps commands in a chroot
bash. This only happens with a lenny/sid chroot, but not with etch.
The major difference is probably the updare to glibc2.7. Since
IP28 isn't really a nice R10k machine, it would be good, if someone
with a working IP27/IP30 could try a lenny/sid chroot and tell us,
if it's working/not working.
Thanks in advance.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: Cache aliasing issues using 4K pages.
From: Luc Perneel @ 2008-01-15 6:50 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <20080115015814.GF9693@networkno.de>
[-- Attachment #1: Type: text/plain, Size: 2062 bytes --]
On Jan 15, 2008 2:58 AM, Thiemo Seufer <ths@networkno.de> wrote:
> The Engineer wrote:
> > We are working with a 2.6.12 kernel on a dual-core mips architecture.
> > In this dual-core system, one core is running the linux kernel and the
> > other is used for some real-time handling (not directly controlled by
> > Linux)
> > We had different stability issues, which could be pinpointed to be
> > related with cache aliasing problems.
> > Cache aliasing happens when the same physical memory can be cached
> > twice as it is accessed by two different virtual addresses.
> > Indeed, for the index to select the correct cache line the virtual
> > address is used. If some bits of the virtual page address are used in
> > the cache index, aliasing can occur.
> >
> >
> > As there is no hardware solution in the mips to recover from this
> > (which would provide some cache coherency, even for one core), the
> > only intrinsic safe solution is to enlarge the page size, so that
> > cache indexing is only done by the offset address in the page (thus
> > the physical part of the address).
> > Another solution is to flush the cache if a page is being remapped to
> > an aliased address (but in our case linux does not has control on the
> > second core, which can cause issues with shared data between both
> > cores).
> > Currently the second solution is used in the kernel, but we found
> > different issues with it (for instance: we had to merge more recent
> > mips kernels, to get a reliable copy-on-write behaviour after
> > forks...).
> >
> > Therefore some questions:
> > - Are there still some known issues with cache aliasing in the MIPS
> kernel?
> > - Are there known issues when using 16KB pages (8KB pages seems not be
> > possible due to tlb issues).
>
> With recent kernels and toolchains 16k pages work ok IME. With a 2.6.12
> kernel however you'll have to backport a serious amount of bugfixes
> before 16k pages can work. Upgrading the kernel is probably less work.
>
> Thiemo
>
Thanks for the info, any idea from which kernel this works ok?
Luc
[-- Attachment #2: Type: text/html, Size: 2509 bytes --]
^ permalink raw reply
* Re: [SPAM] Cache aliasing issues using 4K pages.
From: Luc Perneel @ 2008-01-15 6:34 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <ECBAEAB5-2C07-4FAA-AB8F-71038F9D3D4F@27m.se>
[-- Attachment #1: Type: text/plain, Size: 2738 bytes --]
It is a real SMP system (you could run linux on it using both cores just
like on a dual core x86 desktop).
Never the less, only one of the cores is running linux. the other runs the
real-time part.
We use a kernel module and shared memory to communicate from the linux
applications to the real-time part on the second core.
Thus the HW is SMP, the software is not...
Luc
On Jan 14, 2008 11:34 PM, Markus Gothe <markus.gothe@27m.se> wrote:
> Lemme guess, it's not a dual-core as in SMP but a sub-CPU.This usually
> involves that the memory differs, for example does it have a TLB. Which
> vendor and which core is it? I suppose you use some sort of firmware from
> the vendor to access the sub-CPU, right?
>
> //Markus
>
> On 14 Jan 2008, at 21:25, The Engineer wrote:
>
> We are working with a 2.6.12 kernel on a dual-core mips architecture.
> In this dual-core system, one core is running the linux kernel and the
> other is used for some real-time handling (not directly controlled by
> Linux)
> We had different stability issues, which could be pinpointed to be
> related with cache aliasing problems.
> Cache aliasing happens when the same physical memory can be cached
> twice as it is accessed by two different virtual addresses.
> Indeed, for the index to select the correct cache line the virtual
> address is used. If some bits of the virtual page address are used in
> the cache index, aliasing can occur.
>
>
> As there is no hardware solution in the mips to recover from this
> (which would provide some cache coherency, even for one core), the
> only intrinsic safe solution is to enlarge the page size, so that
> cache indexing is only done by the offset address in the page (thus
> the physical part of the address).
> Another solution is to flush the cache if a page is being remapped to
> an aliased address (but in our case linux does not has control on the
> second core, which can cause issues with shared data between both
> cores).
> Currently the second solution is used in the kernel, but we found
> different issues with it (for instance: we had to merge more recent
> mips kernels, to get a reliable copy-on-write behaviour after
> forks...).
>
> Therefore some questions:
> - Are there still some known issues with cache aliasing in the MIPS
> kernel?
> - Are there known issues when using 16KB pages (8KB pages seems not be
> possible due to tlb issues).
>
> Thanks in advance,
> Luc
>
>
> _______________________________________
>
> Mr Markus Gothe
> Software Engineer
>
> Phone: +46 (0)13 21 81 20 (ext. 1046)
> Fax: +46 (0)13 21 21 15
> Mobile: +46 (0)70 348 44 35
> Diskettgatan 11, SE-583 35 Linköping, Sweden
> www.27m.com
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 4232 bytes --]
^ permalink raw reply
* Re: memory related kernel bug on cobalt raq2
From: Yoichi Yuasa @ 2008-01-15 6:32 UTC (permalink / raw)
To: Noah Meyerhans; +Cc: yoichi_yuasa, linux-mips
In-Reply-To: <20080114153114.GN3899@morgul.net>
On Mon, 14 Jan 2008 10:31:14 -0500
Noah Meyerhans <frodo@morgul.net> wrote:
> Hi all. I know this has come up in the past, but in case it's helpful, I
> figured I'd report that the kernel bug previously reported at (at least)
> http://www.linux-mips.org/archives/linux-mips/2007-10/msg00093.html is still
> present in current git kernels (more recently observed in
> 2.6.24-rc7-raq2-gaeb7040e-dirty). Here's the kernel output:
Do you use swap on your raq2?
Yoichi
^ permalink raw reply
* Re: Cache aliasing issues using 4K pages.
From: Thiemo Seufer @ 2008-01-15 1:58 UTC (permalink / raw)
To: The Engineer; +Cc: linux-mips
In-Reply-To: <1a18fe6d0801141225u2395ae6dj39d268014019b4a1@mail.gmail.com>
The Engineer wrote:
> We are working with a 2.6.12 kernel on a dual-core mips architecture.
> In this dual-core system, one core is running the linux kernel and the
> other is used for some real-time handling (not directly controlled by
> Linux)
> We had different stability issues, which could be pinpointed to be
> related with cache aliasing problems.
> Cache aliasing happens when the same physical memory can be cached
> twice as it is accessed by two different virtual addresses.
> Indeed, for the index to select the correct cache line the virtual
> address is used. If some bits of the virtual page address are used in
> the cache index, aliasing can occur.
>
>
> As there is no hardware solution in the mips to recover from this
> (which would provide some cache coherency, even for one core), the
> only intrinsic safe solution is to enlarge the page size, so that
> cache indexing is only done by the offset address in the page (thus
> the physical part of the address).
> Another solution is to flush the cache if a page is being remapped to
> an aliased address (but in our case linux does not has control on the
> second core, which can cause issues with shared data between both
> cores).
> Currently the second solution is used in the kernel, but we found
> different issues with it (for instance: we had to merge more recent
> mips kernels, to get a reliable copy-on-write behaviour after
> forks...).
>
> Therefore some questions:
> - Are there still some known issues with cache aliasing in the MIPS kernel?
> - Are there known issues when using 16KB pages (8KB pages seems not be
> possible due to tlb issues).
With recent kernels and toolchains 16k pages work ok IME. With a 2.6.12
kernel however you'll have to backport a serious amount of bugfixes
before 16k pages can work. Upgrading the kernel is probably less work.
Thiemo
^ permalink raw reply
* [PATCH -v2][MIPS] Add Atlas to feature-removal-schedule.txt
From: Dmitri Vorobiev @ 2008-01-14 23:24 UTC (permalink / raw)
To: Ralf Baechle, linux-mips; +Cc: Linux-kernel
Ralf Baechle on Atlas board support in the linux-mips mailing list:
> Maciej is promising to fix it up since a few years ;-) Aside of that it's
> safe to say the Atlas is dead like a coffin nail.
Signed-off-by: Dmitri Vorobiev <dmitri.vorobiev@gmail.com>
---
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 20c4c8b..2693ebc 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -333,3 +333,11 @@ Why: This driver has been marked obsolet
Who: Stephen Hemminger <shemminger@linux-foundation.org>
---------------------------
+
+What: Support for MIPS Technologies' Atlas evaluation board
+When: March 2008
+Why: Apparently there is no user base left for this platform.
+ Hardware out of production since several years.
+Who: Dmitri Vorobiev <dmitri.vorobiev@gmail.com>
+
+---------------------------
^ permalink raw reply related
* Re: [SPAM] [PATCH][MIPS] Add Atlas to feature-removal-schedule.
From: Dmitri Vorobiev @ 2008-01-14 23:18 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Ralf Baechle, linux-mips, Linux-kernel
In-Reply-To: <Pine.LNX.4.64.0801142302001.2335@anakin>
Geert Uytterhoeven wrote:
> On Tue, 15 Jan 2008, Dmitri Vorobiev wrote:
>> Ralf Baechle on Atlas board support in the linux-mips mailing list:
>>
>> Maciej is promising to fix it up since a few years ;-) Aside of that it's
>> safe to say the Atlas is dead like a coffin nail.
>>
>> Signed-off-by: Dmitri Vorobiev <dmitri.vorobiev@gmail.com>
>> ---
>> Documentation/feature-removal-schedule.txt | 8 ++++++++
>> 1 files changed, 8 insertions(+), 0 deletions(-)
>>
>> diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
>> index 20c4c8b..c053318 100644
>> --- a/Documentation/feature-removal-schedule.txt
>> +++ b/Documentation/feature-removal-schedule.txt
>> @@ -333,3 +333,11 @@ Why: This driver has been marked obsolete for many years.
>> Who: Stephen Hemminger <shemminger@linux-foundation.org>
>>
>> ---------------------------
>> +
>> +What: Support for MIPS Technologies' Altas evaluation board
> ^^^^^
> Atlas
This is what happens when doing things in a rush. Thanks, Geert.
I'll post a corrected version soon.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
^ permalink raw reply
* Re: [SPAM] Cache aliasing issues using 4K pages.
From: Markus Gothe @ 2008-01-14 22:34 UTC (permalink / raw)
To: The Engineer; +Cc: linux-mips
In-Reply-To: <1a18fe6d0801141225u2395ae6dj39d268014019b4a1@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2253 bytes --]
Lemme guess, it's not a dual-core as in SMP but a sub-CPU.
This usually involves that the memory differs, for example does it
have a TLB. Which vendor and which core is it? I suppose you use some
sort of firmware from the vendor to access the sub-CPU, right?
//Markus
On 14 Jan 2008, at 21:25, The Engineer wrote:
> We are working with a 2.6.12 kernel on a dual-core mips architecture.
> In this dual-core system, one core is running the linux kernel and the
> other is used for some real-time handling (not directly controlled by
> Linux)
> We had different stability issues, which could be pinpointed to be
> related with cache aliasing problems.
> Cache aliasing happens when the same physical memory can be cached
> twice as it is accessed by two different virtual addresses.
> Indeed, for the index to select the correct cache line the virtual
> address is used. If some bits of the virtual page address are used in
> the cache index, aliasing can occur.
>
>
> As there is no hardware solution in the mips to recover from this
> (which would provide some cache coherency, even for one core), the
> only intrinsic safe solution is to enlarge the page size, so that
> cache indexing is only done by the offset address in the page (thus
> the physical part of the address).
> Another solution is to flush the cache if a page is being remapped to
> an aliased address (but in our case linux does not has control on the
> second core, which can cause issues with shared data between both
> cores).
> Currently the second solution is used in the kernel, but we found
> different issues with it (for instance: we had to merge more recent
> mips kernels, to get a reliable copy-on-write behaviour after
> forks...).
>
> Therefore some questions:
> - Are there still some known issues with cache aliasing in the MIPS
> kernel?
> - Are there known issues when using 16KB pages (8KB pages seems not be
> possible due to tlb issues).
>
> Thanks in advance,
> Luc
>
_______________________________________
Mr Markus Gothe
Software Engineer
Phone: +46 (0)13 21 81 20 (ext. 1046)
Fax: +46 (0)13 21 21 15
Mobile: +46 (0)70 348 44 35
Diskettgatan 11, SE-583 35 Linköping, Sweden
www.27m.com
[-- Attachment #1.2: Type: text/html, Size: 4929 bytes --]
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 194 bytes --]
^ permalink raw reply
* Re: [SPAM] [PATCH][MIPS] Add Atlas to feature-removal-schedule.
From: Geert Uytterhoeven @ 2008-01-14 22:02 UTC (permalink / raw)
To: Dmitri Vorobiev; +Cc: Ralf Baechle, linux-mips, Linux-kernel
In-Reply-To: <478BD0D2.2060004@gmail.com>
On Tue, 15 Jan 2008, Dmitri Vorobiev wrote:
> Ralf Baechle on Atlas board support in the linux-mips mailing list:
>
> Maciej is promising to fix it up since a few years ;-) Aside of that it's
> safe to say the Atlas is dead like a coffin nail.
>
> Signed-off-by: Dmitri Vorobiev <dmitri.vorobiev@gmail.com>
> ---
> Documentation/feature-removal-schedule.txt | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
> index 20c4c8b..c053318 100644
> --- a/Documentation/feature-removal-schedule.txt
> +++ b/Documentation/feature-removal-schedule.txt
> @@ -333,3 +333,11 @@ Why: This driver has been marked obsolete for many years.
> Who: Stephen Hemminger <shemminger@linux-foundation.org>
>
> ---------------------------
> +
> +What: Support for MIPS Technologies' Altas evaluation board
^^^^^
Atlas
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH][MIPS] Malta: Fix reading the PCI clock frequency on big-endian
From: Dmitri Vorobiev @ 2008-01-14 21:27 UTC (permalink / raw)
To: Ralf Baechle, linux-mips; +Cc: Linux-kernel
The JMPRS register on Malta boards keeps a 32-bit CPU-endian
value. The readw() function assumes that the value it reads is a
little-endian 16-bit number. Therefore, using readw() to obtain
the value of the JMPRS register is a mistake. This error leads
to incorrect reading of the PCI clock frequency on big-endian
during board start-up.
Change readw() to __raw_readl().
This was tested by injecting a call to printk() and verifying
that the value of the jmpr variable was consistent with current
setting of the JP4 "PCI CLK" jumper.
Signed-off-by: Dmitri Vorobiev <dmitri.vorobiev@gmail.com>
---
arch/mips/mips-boards/malta/malta_setup.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/mips/mips-boards/malta/malta_setup.c b/arch/mips/mips-boards/malta/malta_setup.c
index 9a2636e..bc43a5c 100644
--- a/arch/mips/mips-boards/malta/malta_setup.c
+++ b/arch/mips/mips-boards/malta/malta_setup.c
@@ -149,7 +149,7 @@ void __init plat_mem_setup(void)
/* Check PCI clock */
{
unsigned int __iomem *jmpr_p = (unsigned int *) ioremap(MALTA_JMPRS_REG, sizeof(unsigned int));
- int jmpr = (readw(jmpr_p) >> 2) & 0x07;
+ int jmpr = (__raw_readl(jmpr_p) >> 2) & 0x07;
static const int pciclocks[] __initdata = {
33, 20, 25, 30, 12, 16, 37, 10
};
--
1.5.3
^ permalink raw reply related
* [PATCH][MIPS] Add Atlas to feature-removal-schedule.
From: Dmitri Vorobiev @ 2008-01-14 21:14 UTC (permalink / raw)
To: Ralf Baechle, linux-mips; +Cc: Linux-kernel
Ralf Baechle on Atlas board support in the linux-mips mailing list:
Maciej is promising to fix it up since a few years ;-) Aside of that it's
safe to say the Atlas is dead like a coffin nail.
Signed-off-by: Dmitri Vorobiev <dmitri.vorobiev@gmail.com>
---
Documentation/feature-removal-schedule.txt | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 20c4c8b..c053318 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -333,3 +333,11 @@ Why: This driver has been marked obsolete for many years.
Who: Stephen Hemminger <shemminger@linux-foundation.org>
---------------------------
+
+What: Support for MIPS Technologies' Altas evaluation board
+When: March 2008
+Why: Apparently there is no user base left for this platform.
+ Hardware out of production since several years.
+Who: Dmitri Vorobiev <dmitri.vorobiev@gmail.com>
+
+---------------------------
--
1.5.3
^ permalink raw reply related
* Cache aliasing issues using 4K pages.
From: The Engineer @ 2008-01-14 20:25 UTC (permalink / raw)
To: linux-mips
We are working with a 2.6.12 kernel on a dual-core mips architecture.
In this dual-core system, one core is running the linux kernel and the
other is used for some real-time handling (not directly controlled by
Linux)
We had different stability issues, which could be pinpointed to be
related with cache aliasing problems.
Cache aliasing happens when the same physical memory can be cached
twice as it is accessed by two different virtual addresses.
Indeed, for the index to select the correct cache line the virtual
address is used. If some bits of the virtual page address are used in
the cache index, aliasing can occur.
As there is no hardware solution in the mips to recover from this
(which would provide some cache coherency, even for one core), the
only intrinsic safe solution is to enlarge the page size, so that
cache indexing is only done by the offset address in the page (thus
the physical part of the address).
Another solution is to flush the cache if a page is being remapped to
an aliased address (but in our case linux does not has control on the
second core, which can cause issues with shared data between both
cores).
Currently the second solution is used in the kernel, but we found
different issues with it (for instance: we had to merge more recent
mips kernels, to get a reliable copy-on-write behaviour after
forks...).
Therefore some questions:
- Are there still some known issues with cache aliasing in the MIPS kernel?
- Are there known issues when using 16KB pages (8KB pages seems not be
possible due to tlb issues).
Thanks in advance,
Luc
^ permalink raw reply
* Re: [PATCH] Kill Broadcom machine group
From: Ralf Baechle @ 2008-01-14 19:57 UTC (permalink / raw)
To: Florian Fainelli; +Cc: linux-mips
In-Reply-To: <200801141900.02601.florian.fainelli@telecomint.eu>
On Mon, Jan 14, 2008 at 07:00:01PM +0100, Florian Fainelli wrote:
> This patch removes the remaining MACH_GROUP that
> was still present for Broadcom boards.
>
> Signed-off-by: Florian Fainelli <florian.fainelli@telecomint.eu>
Patch good - but Yoichi Yuasa's patch "remove unused mips_machtype" from
October already cleaned that.
Ralf
^ permalink raw reply
* [PATCH] Kill Broadcom machine group
From: Florian Fainelli @ 2008-01-14 18:00 UTC (permalink / raw)
To: linux-mips; +Cc: ralf
This patch removes the remaining MACH_GROUP that
was still present for Broadcom boards.
Signed-off-by: Florian Fainelli <florian.fainelli@telecomint.eu>
---
diff --git a/include/asm-mips/bootinfo.h b/include/asm-mips/bootinfo.h
index b2dd9b3..070a957 100644
--- a/include/asm-mips/bootinfo.h
+++ b/include/asm-mips/bootinfo.h
@@ -195,8 +195,7 @@
/*
* Valid machtype for group Broadcom
*/
-#define MACH_GROUP_BRCM 23 /* Broadcom */
-#define MACH_BCM47XX 1 /* Broadcom BCM47XX */
+#define MACH_BCM47XX 1 /* Broadcom BCM47XX */
#define CL_SIZE COMMAND_LINE_SIZE
^ permalink raw reply related
* Re: [PATCH] prom_free_prom_memory for QEMU
From: Dmitri Vorobiev @ 2008-01-14 17:47 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Atsushi Nemoto, linux-mips
In-Reply-To: <20080114165759.GA2894@linux-mips.org>
Ralf Baechle wrote:
> On Mon, Jan 14, 2008 at 07:43:12PM +0300, Dmitri Vorobiev wrote:
>
>>>>> I was actually planning to remove the Qemu platform for 2.6.25. The
>>>>> Malta emulation has become so good that there is no more point in having
>>>>> the underfeatured synthetic platform that CONFIG_QEMU is.
>>>> I wholeheartedly agree with that. It is a godsend to me that I can use
>>>> identical configs to build the kernels for QEMU and for a physical Malta.
>>>> Emulation is more convenient to me because QEMU boots and runs faster
>>>> than the board I'm working with. Many thanks for that to QEMU developers.
>>>>
>>>> Off the topic, how about the plans to remove Atlas support?
>>> Maciej is promising to fix it up since a few years ;-) Aside of that it's
>>> safe to say the Atlas is dead like a coffin nail.
>> Well, I could do the proper cleanup, if you give your sayso. As I wrote here
>> yesterday, I noticed that Malta code was screaming for being put into proper
>> shape. If MIPS maintainers are interested in applying such janitorial patches,
>> I could simultaneously wipe the Atlas support off.
>>
>> So?
>
> Of course janitorial patches will be considered.
I'm rolling up the sleeves.
>
> The Malta code used to scream even way louder. I made an opportunistic
> attempt at fixing the one or other corner over time, whenever something
> was getting in my way for some reason.
I see. Actually, I am teaching system programming at the premises of the Moscow
State University and I am now working on a lab assignment where a Malta board
will be involved. In the classes, I insist that my students follow the coding
style rules to the letter, that's why I really want the Malta code to be
worthy of imitation. :)
>
> Ralf
>
^ permalink raw reply
* Re: memory related kernel bug on cobalt raq2
From: David Daney @ 2008-01-14 17:22 UTC (permalink / raw)
To: Noah Meyerhans; +Cc: linux-mips
In-Reply-To: <20080114153114.GN3899@morgul.net>
Noah Meyerhans wrote:
> Hi all. I know this has come up in the past, but in case it's helpful, I
> figured I'd report that the kernel bug previously reported at (at least)
> http://www.linux-mips.org/archives/linux-mips/2007-10/msg00093.html is still
> present in current git kernels (more recently observed in
> 2.6.24-rc7-raq2-gaeb7040e-dirty). Here's the kernel output:
>
> Kernel bug detected[#1]:
> Cpu 0
> $ 0 : 00000000 b000ec00 00000001 00000004
> $ 4 : 81107760 7fb60f09 0000000e 83fb6000
> $ 8 : 00000f09 7fb60f09 800f5fe8 00000000
> $12 : 00000000 00000000 83ea6cc0 004038b4
> $16 : 81107760 0000000e 83fb6000 7fb60f09
> $20 : 803c0000 8fdf2cc0 00000000 86015e28
> $24 : 00000006 8008d480
> $28 : 86014000 86015de0 86015e2c 8008b2cc
> Hi : 00000000
> Lo : 00000000
> epc : 8008af9c kmap_coherent+0xc/0xe0 Not tainted
> ra : 8008b2cc copy_from_user_page+0xb0/0xe4
> Status: b000ec03 KERNEL EXL IE
> Cause : 00800034
> PrId : 000028a0 (Nevada)
> Process cat (pid: 5739, threadinfo=86014000, task=804b9178)
> Stack : 8fdf2cc0 7fb60f09 83fb6000 0000000e 0000000e 7fb60f09 83fb6000 00000000
> 0000000e 800e0484 8fc75178 804b9178 000800d0 00000000 883bbf09 0000000e
> 86015e2c 86015e28 8fe0dbfc 81107760 8fdf2cf4 00000000 8fdf2cc0 00000000
> 0000000e 83fb6000 00000400 8fc75178 00001000 0052c7c8 00000000 80133f5c
> 8fc75178 8fa26704 83fb6000 86015f18 00000000 0052c7c8 8fc75178 83fb6000
> ...
> Call Trace:
> [<8008af9c>] kmap_coherent+0xc/0xe0
> [<8008b2cc>] copy_from_user_page+0xb0/0xe4
> [<800e0484>] access_process_vm+0x178/0x21c
> [<80133f5c>] proc_pid_cmdline+0xa4/0x14c
> [<80136300>] proc_info_read+0x104/0x144
> [<800f5a7c>] vfs_read+0xc0/0x160
> [<800f603c>] sys_read+0x54/0xa0
> [<80088cac>] stack_done+0x20/0x3c
>
Yes, this would seem to be the same problem as:
http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=20071211221327.GB2150%40paradigm.rfc822.org
There is a similar problem in 2.6.23.
David Daney
^ permalink raw reply
* Re: [PATCH] prom_free_prom_memory for QEMU
From: Ralf Baechle @ 2008-01-14 16:57 UTC (permalink / raw)
To: Dmitri Vorobiev; +Cc: Atsushi Nemoto, linux-mips
In-Reply-To: <478B9120.1020500@gmail.com>
On Mon, Jan 14, 2008 at 07:43:12PM +0300, Dmitri Vorobiev wrote:
> >>> I was actually planning to remove the Qemu platform for 2.6.25. The
> >>> Malta emulation has become so good that there is no more point in having
> >>> the underfeatured synthetic platform that CONFIG_QEMU is.
> >> I wholeheartedly agree with that. It is a godsend to me that I can use
> >> identical configs to build the kernels for QEMU and for a physical Malta.
> >> Emulation is more convenient to me because QEMU boots and runs faster
> >> than the board I'm working with. Many thanks for that to QEMU developers.
> >>
> >> Off the topic, how about the plans to remove Atlas support?
> >
> > Maciej is promising to fix it up since a few years ;-) Aside of that it's
> > safe to say the Atlas is dead like a coffin nail.
>
> Well, I could do the proper cleanup, if you give your sayso. As I wrote here
> yesterday, I noticed that Malta code was screaming for being put into proper
> shape. If MIPS maintainers are interested in applying such janitorial patches,
> I could simultaneously wipe the Atlas support off.
>
> So?
Of course janitorial patches will be considered.
The Malta code used to scream even way louder. I made an opportunistic
attempt at fixing the one or other corner over time, whenever something
was getting in my way for some reason.
Ralf
^ permalink raw reply
* Re: [PATCH] prom_free_prom_memory for QEMU
From: Dmitri Vorobiev @ 2008-01-14 16:43 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Atsushi Nemoto, linux-mips
In-Reply-To: <20080114141424.GB22344@linux-mips.org>
Ralf Baechle wrote:
> On Mon, Jan 14, 2008 at 04:58:59PM +0300, Dmitri Vorobiev wrote:
>
>>> I was actually planning to remove the Qemu platform for 2.6.25. The
>>> Malta emulation has become so good that there is no more point in having
>>> the underfeatured synthetic platform that CONFIG_QEMU is.
>> I wholeheartedly agree with that. It is a godsend to me that I can use
>> identical configs to build the kernels for QEMU and for a physical Malta.
>> Emulation is more convenient to me because QEMU boots and runs faster
>> than the board I'm working with. Many thanks for that to QEMU developers.
>>
>> Off the topic, how about the plans to remove Atlas support?
>
> Maciej is promising to fix it up since a few years ;-) Aside of that it's
> safe to say the Atlas is dead like a coffin nail.
Well, I could do the proper cleanup, if you give your sayso. As I wrote here
yesterday, I noticed that Malta code was screaming for being put into proper
shape. If MIPS maintainers are interested in applying such janitorial patches,
I could simultaneously wipe the Atlas support off.
So?
>
> The main problem with the Atlas is the SAA9730 SOC which is broken in an
> infinite number of totally pervert ways, I'm told. I know of no systems
> other than the Atlas using it.
>
> Ralf
>
^ permalink raw reply
* memory related kernel bug on cobalt raq2
From: Noah Meyerhans @ 2008-01-14 15:31 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 1821 bytes --]
Hi all. I know this has come up in the past, but in case it's helpful, I
figured I'd report that the kernel bug previously reported at (at least)
http://www.linux-mips.org/archives/linux-mips/2007-10/msg00093.html is still
present in current git kernels (more recently observed in
2.6.24-rc7-raq2-gaeb7040e-dirty). Here's the kernel output:
Kernel bug detected[#1]:
Cpu 0
$ 0 : 00000000 b000ec00 00000001 00000004
$ 4 : 81107760 7fb60f09 0000000e 83fb6000
$ 8 : 00000f09 7fb60f09 800f5fe8 00000000
$12 : 00000000 00000000 83ea6cc0 004038b4
$16 : 81107760 0000000e 83fb6000 7fb60f09
$20 : 803c0000 8fdf2cc0 00000000 86015e28
$24 : 00000006 8008d480
$28 : 86014000 86015de0 86015e2c 8008b2cc
Hi : 00000000
Lo : 00000000
epc : 8008af9c kmap_coherent+0xc/0xe0 Not tainted
ra : 8008b2cc copy_from_user_page+0xb0/0xe4
Status: b000ec03 KERNEL EXL IE
Cause : 00800034
PrId : 000028a0 (Nevada)
Process cat (pid: 5739, threadinfo=86014000, task=804b9178)
Stack : 8fdf2cc0 7fb60f09 83fb6000 0000000e 0000000e 7fb60f09 83fb6000 00000000
0000000e 800e0484 8fc75178 804b9178 000800d0 00000000 883bbf09 0000000e
86015e2c 86015e28 8fe0dbfc 81107760 8fdf2cf4 00000000 8fdf2cc0 00000000
0000000e 83fb6000 00000400 8fc75178 00001000 0052c7c8 00000000 80133f5c
8fc75178 8fa26704 83fb6000 86015f18 00000000 0052c7c8 8fc75178 83fb6000
...
Call Trace:
[<8008af9c>] kmap_coherent+0xc/0xe0
[<8008b2cc>] copy_from_user_page+0xb0/0xe4
[<800e0484>] access_process_vm+0x178/0x21c
[<80133f5c>] proc_pid_cmdline+0xa4/0x14c
[<80136300>] proc_info_read+0x104/0x144
[<800f5a7c>] vfs_read+0xc0/0x160
[<800f603c>] sys_read+0x54/0xa0
[<80088cac>] stack_done+0x20/0x3c
Code: 8c820000 00021242 30420001 <00028036> 8f820014 3c03803d 24420001 af820014 8c62f2a0
Thanks.
noah
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] IP28 fixes
From: Sergei Shtylyov @ 2008-01-14 15:21 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Ralf Baechle, Thomas Bogendoerfer, linux-mips
In-Reply-To: <478B7084.8030401@ru.mvista.com>
I wrote:
>>> - ISA DMA is broken on IP28
>>> - bus error handler improved to not issue bus errors for
>>> speculative accesses to CPU and GIO addresses. We now
>>> treat CSTAT_ADDR and GSTAT_TIME errors as non fatal, when
>>> they are issues via MC error interrupt. For real (non
>>> speculative) bus errors a DBE will be issued, which is
>>> lethal as before. Handling the issue this way gets rid
>>> of decoding instructions
>>> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
>> Folded into the "[MIPS] IP28 support" patch for 2.6.28.
> Poor IP32 will have to wait couple of years? ;-)
I meant IP28 of course. 1:1 in typos. :-)
>> Thanks,
>> Ralf
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] prom_free_prom_memory for QEMU
From: Atsushi Nemoto @ 2008-01-14 14:42 UTC (permalink / raw)
To: ths; +Cc: ralf, linux-mips
In-Reply-To: <20080114143033.GC9693@networkno.de>
On Mon, 14 Jan 2008 14:30:33 +0000, Thiemo Seufer <ths@networkno.de> wrote:
> Debian/unstable had Malta kernels for a while now, installer support
> is currently in the works.
Wonderful! Then I have no objection for dropping QEMU.
---
Atsushi Nemoto
^ permalink raw reply
* Re: [PATCH] prom_free_prom_memory for QEMU
From: Thiemo Seufer @ 2008-01-14 14:30 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: ralf, linux-mips
In-Reply-To: <20080114.225318.63132741.anemo@mba.ocn.ne.jp>
Atsushi Nemoto wrote:
> On Mon, 14 Jan 2008 13:37:01 +0000, Ralf Baechle <ralf@linux-mips.org> wrote:
> > I was actually planning to remove the Qemu platform for 2.6.25. The
> > Malta emulation has become so good that there is no more point in having
> > the underfeatured synthetic platform that CONFIG_QEMU is.
> >
> > Objections?
>
> The Qemu platform is one of officially supported platforms by Debian.
> If Debian did not support the Malta yet, I hope qemu alive.
Debian/unstable had Malta kernels for a while now, installer support
is currently in the works.
Thiemo
^ permalink raw reply
* Re: [PATCH] prom_free_prom_memory for QEMU
From: Thiemo Seufer @ 2008-01-14 14:27 UTC (permalink / raw)
To: Dmitri Vorobiev; +Cc: Atsushi Nemoto, ralf, linux-mips
In-Reply-To: <478B6BBD.90005@gmail.com>
Dmitri Vorobiev wrote:
> Atsushi Nemoto wrote:
> > On Mon, 14 Jan 2008 13:37:01 +0000, Ralf Baechle <ralf@linux-mips.org> wrote:
> >> I was actually planning to remove the Qemu platform for 2.6.25. The
> >> Malta emulation has become so good that there is no more point in having
> >> the underfeatured synthetic platform that CONFIG_QEMU is.
> >>
> >> Objections?
> >
> > The Qemu platform is one of officially supported platforms by Debian.
> > If Debian did not support the Malta yet, I hope qemu alive.
>
> Would you like me to try following the instructions given at
>
> http://www.aurel32.net/info/debian_mips_qemu.php
>
> with QEMU emulating a Malta board? I haven't tried this yet, but I
> feel that the possibility exists that this would work out of the box.
Combining a self-compiled Malta kernel with the Qemu initrd from Debian
works with some minor glitches (like unusable kernel modules in the
installed image). Adding proper support in the Debian installer is
currently ongoing.
Thiemo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox