On Mon, 2005-08-01 at 13:36 -0700, Christoph Lameter wrote:
> Could you get me some more information about the hang? A stacktrace would
> be useful.
I've attached gdb to it and its stuck in memcpy (from glibc). The rest
of the trace is junk as glibc's arm memcpy implementation will have
destroyed the frame pointer. The current instruction is a store to
memory (stmneia r0!, {r3,r4} ) and the instruction pointer isn't
changing...
> Well the device is able to run X so I guess that a slow kernel compile
> would work. At least the embedded device that I used to work on was
> capable of doing that (but then we had Debian on that thing which made
> doing stuff like that very easy).
I agree, it would probably do a slow compile. I have no compiler or
development tools on it though and only slow vfat disks other than the
internal flash. There are plenty of options to get such things working
but it will take me a while to setup.
Hopefully the memcpy clue will mean something?
Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
