tiomap-dev team mailing list archive
-
tiomap-dev team
-
Mailing list archive
-
Message #00421
[Bug 633227] Re: instabilities with highmem activated
I tried latest 2.6.38-rc4 kernel with Angstrom file system. System is very unstable when I building kernel on it. Sometimes BUG() oops filed, sometimes system froze totally. Please find my log here:
http://pastebin.ubuntu.com/566990/
http://pastebin.ubuntu.com/566987/
A friend of mine, Ming Lei who is helping maintaining musb driver of
OMAP tried building kernel on his mass production Panda board. He said
he never met this unstable issue on that. And He recalled that he might
met this issue before on EA Panda board.
So Sebastien, do you have latest mass production Panda board for
testing? I'm suspecting this issue is hardware related.
Thanks,
-Bryan
--
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.