tiomap-dev team mailing list archive

[Sebastien JAN <s-jan@xxxxxx>]

I did re-test with mainline 2.6.38-rc2 kernel (plus few patches from
Linux-Omap tree / omap-testing branch required for booting the
pandaboard on top of .38-rc2).

I was able to reproduce the issue with highmem activated (after 20
minutes or 2hours of native kernel build).

I was not able to reproduce the issue with highmem deactivated and
running native kernel builds for more than 60hours.

Attached is the kernel config I was using (with highmem deactivated) to
boot a Ubuntu file-system with my 2.6.38-rc2+ kernel.


** Attachment added: "config.2.6.38-rc2+usb"
   https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/633227/+attachment/1819409/+files/config.2.6.38-rc2%2Busb

-- 
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.