Subject: Corruption in 2.4.x

From: Geert Uytterhoeven <[email-masked]>
Date: Wed, 11 Jun 2003 17:46:53 +0200 (MEST)

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 -- [email-masked]

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

---

From: Geert Uytterhoeven <[email-masked]>
Date: Fri, 13 Jun 2003 12:14:55 +0200 (MEST)

> /etc/motd, of which the non-first lines are rewritten by the startup scripts on

Just to keep you informed...

Apparently this problem was not caused by Linux, but by the hardware. A few
hours after I sent the previous mail, my IDE disk started showing unrecoverable
read errors on some blocks.  According to the e2fsck badblocks test, /etc/motd
was on a bad block. So most probably the disk started returning wrong data
about one month ago, without detecting there was a read error (lousy ECC and
bad block remapping?).

Now the bad blocks are no longer in active use, everything works fine! Sorry
for the noise.

Gr{oetje,eeting}s,

						Geert