linux-mips
[Top] [All Lists]

Corruption in 2.4.x

To: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Corruption in 2.4.x
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Wed, 11 Jun 2003 17:46:53 +0200 (MEST)
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
        Hi,

Recently we started seeing slight file corruption and random segmentation
faults with the 2.4.x MIPS kernel from CVS. The problems appeared after
upgrading from 2.4.20 (CVS 2003-01-13) to 2.4.21-pre4 (CVS 2003-05-06), which
introduced the new cache/tlb optimizations.

Most prominent indication of the file corruption is the corruption of
/etc/motd, of which the non-first lines are rewritten by the startup scripts on
every boot up.

The CPU contains a VR4120A core, running in big endian mode. It should be very
similar to the core in the VR4131, with the following exceptions:
  - both the instruction and data cache are direct mapped instead of 2-way
    associative
  - the data cache is only 8 KiB instead of 16 KiB

Perhaps this rings a bell?

Our cross-toolchain consists of gcc 3.2.2 and binutils 2.13.2.1. Userland is
Debian (mostly woody).

Relevant part of dmesg:

| CPU revision is: 00000c72
| Primary instruction cache 16kB, physically tagged, direct mapped, linesize 16 
bytes.
| Primary data cache 8kB direct mapped, linesize 16 bytes.

Relevant part of /proc/cpuinfo:

| cpu model               : NEC VR4122 V7.2
| BogoMIPS                : 165.88
| wait instruction        : no
| microsecond timers      : yes
| tlb_entries             : 32
| extra interrupt vector  : no
| hardware watchpoint     : no
| VCED exceptions         : not available
| VCEI exceptions         : not available

Thanks!

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


<Prev in Thread] Current Thread [Next in Thread>