tiomap-dev team mailing list archive

[Sebastien JAN <s-jan@xxxxxx>]

@paolo: I don't think the memtester -p test is relevant: when using the -p option with the whole memory address-able by the kernel you can expect some kernel memory corruption (which you did verify actually):
Here is the memtester man entry for the -p option:
      -p PHYSADDR
              tells  memtester  to  test  a  specific  region  of  memory  starting at physical address PHYSADDR (given in hex), by
              mmap(2)ing /dev/mem.  This is mostly of use to hardware developers, for testing memory-mapped I/O devices  and  simi‐
              lar.   Note  that  the memory region will be overwritten during testing, so it is not safe to specify memory which is
              allocated for the system or for other applications; doing so will cause them to crash.  If you absolutely must test a
              particular region of actual physical memory, arrange to have that memory allocated by your test software, and hold it
              in this allocated state, then run memtester on it with this option.

-- 
You received this bug notification because you are a member of TI OMAP
Developers, which is a direct subscriber.
https://bugs.launchpad.net/bugs/633227

Title:
  instabilities with highmem activated

Status in “linux-ti-omap4” package in Ubuntu:
  Confirmed
Status in “linux-ti-omap4” source package in Maverick:
  Fix Released
Status in “linux-ti-omap4” source package in Natty:
  Confirmed

Bug description:
  Seen on Maverick: 2.6.35-903.9
  HW: pandaboard ES2.0

  Using following kernel memory allocation (in bootargs):
  mem=460M@0x80000000 mem=512M@0xA0000000

  Instabilities have been observed in 2 different ways:

  1) The following memtester test:
  sudo memtester -p 0xb0000000 120
  Fails in few seconds with a "illegal instruction” error.
  Then various behaviors can be seen:  the UI can freeze, shell commands be unavailable. The systems works well again after a reboot.

  2) By doing a native build of a kernel package (with file-system on SD card, and kernel sources on an NFS mount):
  After 15mins to 1h30, a "compiler error: bus error" triggers and the build stops (and the platform hangs).

  
  This issue cannot be reproduced if using mem=460M@0x80000000 mem=256M@0xA000000.
  This issue cannot be reproduced with highmen deactivated from the kernel config.
  This issue can be reproduced with 'nosmp' in kernel command line.