From: Peter Horton <pdh@colonel-panic.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Peter Horton <phorton@bitbox.co.uk>, linux-mips@linux-mips.org
Subject: Re: Kernel 2.4.23 on Cobalt Qube2 - area of problem
Date: Sat, 13 Dec 2003 18:20:52 +0000 [thread overview]
Message-ID: <20031213182052.GB480@skeleton-jack> (raw)
In-Reply-To: <20031213170751.GB13271@linux-mips.org>
On Sat, Dec 13, 2003 at 06:07:51PM +0100, Ralf Baechle wrote:
> On Fri, Dec 12, 2003 at 10:45:08AM +0000, Peter Horton wrote:
>
> > More info on the random segmentation faults and data corruption on my Qube2.
> >
> > 2.4.21 from CVS is the first kernel to exhibit the problem. I tracked it
> > down to the cache handling changes that went in between 2.4.20 and 2.4.21.
> >
> > By (not very scientifically) removing flush_dcache_page() and
> > re-instating flush_page_to_ram() I managed to get the 2.4.21 kernel
> > stable (see attached patch). Applying a similiar patch to 2.4.23 (CVS
> > HEAD) allows me to run 2.4.23 too.
> >
> > I don't know how to track the problem any further - the kernel's cache
> > handling is a bit out of my league.
> >
> > Anyone got a clue stick they can point me in the right direction with ?
>
> Can you put a printk into c-r4k.c and print the value of the
> shm_align_mask variable? I want to make sure it's got a sane value on
> your box. Also the first few lines of your bootup messages with the
> processor and cache stuff would be useful.
>
See below. All the cache settings and the shm_align_mask look fine
according to the RM5231 data sheet I have here.
At the moment the only change I make from the linux_2_4 HEAD kernel is
to update include/asm-mips/cacheflush.h so:
-#define flush_page_to_ram(page) do { } while(0)
+#define flush_page_to_ram(page) flush_dcache_page(page)
This single change gives me a rock solid kernel, so it masks the problem
somehow.
P.
CPU revision is: 000028a0
FPU revision is: 000028a0
D-cache:
size 32768
linesz 32
sets 512
ways 2
waysize 16384
waybit 14
I-cache:
size 32768
linesz 32
sets 512
ways 2
waysize 16384
waybit 14
Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes.
Primary data cache 32kB 2-way, linesize 32 bytes.
shm_align_mask 0x3fff
Linux version 2.4.23 (pdh@skeleton-jack) (gcc version 2.95.4 20011002 (Debian prerelease)) #6 Sat Dec 13 18:13:09 GMT 2003
Determined physical RAM map:
memory: 02000000 @ 00000000 (usable)
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,115200 ide1=noprobe root=/dev/hda2
ide_setup: ide1=noprobe
Calibrating delay loop... 249.03 BogoMIPS
Memory: 30380k/32768k available (1147k kernel code, 2388k reserved, 168k data, 100k init, 0k highmem)
...
next prev parent reply other threads:[~2003-12-13 18:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-12 10:45 Kernel 2.4.23 on Cobalt Qube2 - area of problem Peter Horton
2003-12-13 17:07 ` Ralf Baechle
2003-12-13 18:20 ` Peter Horton [this message]
2003-12-13 18:38 ` Peter Horton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031213182052.GB480@skeleton-jack \
--to=pdh@colonel-panic.org \
--cc=linux-mips@linux-mips.org \
--cc=phorton@bitbox.co.uk \
--cc=ralf@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.