From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7281 invoked by alias); 7 Apr 2013 05:39:24 -0000 Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org Received: (qmail 7271 invoked by uid 89); 7 Apr 2013 05:39:24 -0000 X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Sun, 07 Apr 2013 05:39:18 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 21B514680008 for ; Sun, 7 Apr 2013 06:39:15 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4lVAjnovahN; Sun, 7 Apr 2013 06:39:08 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001814] Kinetis clock gating Date: Sun, 07 Apr 2013 05:39:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: mjones@linear.com X-Bugzilla-Status: NEW X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-04/txt/msg00029.txt.bz2 Please do not reply to this email, use the link below. http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814 --- Comment #19 from Mike Jones --- I worked though patches one by one until a problem was found with Ilija's help. I was using the diag for shell IO rather than tty3, and this caused a problem. Diag polls and that used up much of the CPU. That exposed a SPI bug that caused a loop on status to never complete. Ilija created a patch for that. That got most of my application up. I am now down to one problem. A malloc no longer works. Here is what my heap and stack look like: STACK ----- thread pri base size used percent state name 1 31 0x1fff6418 2048 260 12.7 0 Idle Thread 2 4 0x1fff1808 2048 1484 72.5 16 setup_thread 3 5 0x1fff2008 2048 336 16.4 1 alert_thread 4 6 0x1fff2a08 2048 792 38.7 1 telemetry_monitor_thread 5 7 0x1fff2808 512 212 41.4 1 telemetry_thread 6 10 0x1fff3208 4096 1588 38.8 0 shell_thread 7 11 0x1fff4208 1024 660 64.5 16 network_thread 8 8 0x1fff9a08 4096 644 15.7 1 tcpip 9 4 0x1fffaa08 4096 188 4.6 1 eth 10 7 0x1fff460c 2048 384 18.8 1 telnet 11 7 0x1fff4e0c 2048 336 16.4 1 ftp 12 7 0x1fff560c 1024 480 46.9 1 snmp HEAP ---- arena 26464 fordblks 13756 fsmblks 0 hblkhd 0 hblks 0 keepcost 0 maxfree 13756 ordblks 1 smblks 0 uordblks 12688 usmblks 0 My malloc statement: hex_data = (char*) malloc(17000); Then down in dlmalloc.cxx remainder_size = long_sub_size_t(chunksize(top), nb); if (chunksize(top) < nb || remainder_size < (long)MINSIZE) { diag_printf("chunksize(top)=%ld, nb=%d, remainder=%ld\n", chunksize(top), nb, remainder_size); MALLOC_UNLOCK; CYG_MEMALLOC_FAIL(bytes); return NULL; /* propagate failure */ } This returns null. The diag print displays: chunksize(top)=13776, nb=17008, remainder=-3232 I tried to turn on the debug build, but I get the following ASSERT: ASSERT FAIL: <1>thread.inl[186]void Cyg_HardwareThread::attach_stack() Stack size too small ASSERT FAIL: <1>thread.inl [ 186] void Cyg_HardwareThread::attach_stack() l I tried to increase the idle thread stack size but could not get by this. If anyone knows how to make the debug work, that might help me get data. If I have to guess, the Doug Lea malloc has some chunk size, and no malloc bigger than will work. At this point in the game, my code and ecc file are very close to what used to work. I only tweak a line related to a different parameter order in a GPIO call. And the ecc is the same other than the new stuff from the patches. 26K of heap is what I had before all this was patched. When I diff'ed my ecc file with the old one, I find no differences related to malloc settings. I notice there is a fall back heap size CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE of 16384. If this is the heap size, my request would fail. But my print out of the heap says it is 26K. So I believe the heap is externally defined. I looked around and did not find any settings in the config tool to set the block size. I don't have time to learn how the malloc works at the moment. I suppose it is possible the chunk size is calculated and sensitive to space or some subtle change from these patches. Bottom line for now is, the whole application seems to work other than this large malloc. Therefore, committing the code would break my app unless I rewrote this section to work in smaller chunks. That would be a lot of work given the way the code works, but I can't elaborate on this code. It is a very complex data processing algorithm that would be hard to make work in chunks, especially with my project deadlines. -- You are receiving this mail because: You are on the CC list for the bug.